Re: [Pharo-project] Socket question (Was Re: Xtreams up to date)
BTW, would this snippet be useful as a basic Socket smoke test ? Or is that already covered somewhere ? | input output listener process sync | sync := Semaphore new. listener := Socket newTCP. listener listenOn: 9999 backlogSize: 10. process := [ [ input := listener waitForAcceptFor: 10. sync signal ] ensure: [ listener close ] ] fork. output := Socket newTCP. output connectTo: #[127 0 0 1] port: 9999. sync wait. [ #( 64 1024 2048 4096 8192 ) do: [:dataSize || data | data := ByteArray new: dataSize. 1 to: data size do: [:i | data at: i put: (i - 1) \\ 256]. 1 to: 10 do: [:each | output sendData: data]. 1 to: 10 do: [ :each || result index | index := 1. result := ByteArray new: dataSize. [ index := index + (input receiveDataInto: result startingAt: index). index > dataSize ] whileFalse. result = data ifFalse: [ result halt]]] ] ensure: [ output close. input close ]
I am really bothered by the timeout on the accept, so much so that I think it has no place in the tests. Of course, one needs a way to clean up after a failure, but that should be done by another thread that waits for a "long" time and then cleans up anything that is left behind after the failure. Servers should be started and stopped and in between, they should wait for and accept connections. Clients should try to connect until told otherwise; timeouts can be reasonable options there, but should not be forced by the sockets system. Only the calling threads should be blocked, of course. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of mkobetic@gmail.com [mkobetic@gmail.com] Sent: Friday, January 14, 2011 1:12 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Socket question (Was Re: Xtreams up to date) BTW, would this snippet be useful as a basic Socket smoke test ? Or is that already covered somewhere ? | input output listener process sync | sync := Semaphore new. listener := Socket newTCP. listener listenOn: 9999 backlogSize: 10. process := [ [ input := listener waitForAcceptFor: 10. sync signal ] ensure: [ listener close ] ] fork. output := Socket newTCP. output connectTo: #[127 0 0 1] port: 9999. sync wait. [ #( 64 1024 2048 4096 8192 ) do: [:dataSize || data | data := ByteArray new: dataSize. 1 to: data size do: [:i | data at: i put: (i - 1) \\ 256]. 1 to: 10 do: [:each | output sendData: data]. 1 to: 10 do: [ :each || result index | index := 1. result := ByteArray new: dataSize. [ index := index + (input receiveDataInto: result startingAt: index). index > dataSize ] whileFalse. result = data ifFalse: [ result halt]]] ] ensure: [ output close. input close ]
On 14 Jan 2011, at 12:54, Schwab,Wilhelm K wrote:
I am really bothered by the timeout on the accept, so much so that I think it has no place in the tests. Of course, one needs a way to clean up after a failure, but that should be done by another thread that waits for a "long" time and then cleans up anything that is left behind after the failure.
Servers should be started and stopped and in between, they should wait for and accept connections. Clients should try to connect until told otherwise; timeouts can be reasonable options there, but should not be forced by the sockets system. Only the calling threads should be blocked, of course.
I don't understand why this would bother you: it is the 'client/user' that decides about the timeout (you could use some very large number for an 'infinite' timeout). You need of course a loop around it. Here is the code from ZnSingleThreadedServer (which started from the Blackfoot example): listenLoop "We create a listening Socket, then wait for a connection. After each connection we also check that the listening Socket is still valid - if not we just make a recursive call to this method to start over." self initializeServerSocket. [ [ serverSocket isValid ifFalse: [ "will trigger #ifCurtailed: block and destroy socket" ^ self listenLoop ]. self serveConnectionOn: serverSocket ] repeat ] ifCurtailed: [ self releaseServerSocket ] serveConnectionOn: listeningSocket "We wait up to acceptWaitTimeout seconds for an incoming connection. If we get one we wrap it in a SocketStream and #executeOneRequestResponseOn: on it" | stream socket | socket := (listeningSocket waitForAcceptFor: self acceptWaitTimeout) ifNil: [ ^ self log: 'Wait for accept timed out' ]. stream := ZnNetworkingUtils socketStreamOn: socket. [ [ [ self executeOneRequestResponseOn: stream ] ensure: [ self log: 'Closing stream'. stream close ] ] ifCurtailed: [ self log: 'Destroying socket'. socket destroy ] ] forkAt: Processor highIOPriority named: 'Zinc HTTP Server Worker' Each #acceptWaitTimeout seconds, 'Wait for accept timed out' is printed on the log and another accept/wait starts. This looping improves liveliness and responsiveness to other events. Sven
Sven, Thanks for the code! The fact that I have to decide what constitutes an "infinite" delay seems wrong to me. It should just do what I tell it and either calmly wait for an event to let the code move forward (assuming that only the calling thread is blocked). One example: if I know I typed an incorrect address, then any time is wasted. If it's correct and the connection is slow (I downloaded a pdf of a paper earlier this week, and it was miserably slow but worked fine), I probably want the code to keep running without trying to think for itself. "This looping improves liveliness and responsiveness to other events." Why does looping on things that should be blocking until events arrive improve response to other events? This seems like a bailing wire solution to the problem. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Sven Van Caekenberghe [sven@beta9.be] Sent: Friday, January 14, 2011 9:36 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Socket question (Was Re: Xtreams up to date) On 14 Jan 2011, at 12:54, Schwab,Wilhelm K wrote: I don't understand why this would bother you: it is the 'client/user' that decides about the timeout (you could use some very large number for an 'infinite' timeout). You need of course a loop around it. Here is the code from ZnSingleThreadedServer (which started from the Blackfoot example): listenLoop "We create a listening Socket, then wait for a connection. After each connection we also check that the listening Socket is still valid - if not we just make a recursive call to this method to start over." self initializeServerSocket. [ [ serverSocket isValid ifFalse: [ "will trigger #ifCurtailed: block and destroy socket" ^ self listenLoop ]. self serveConnectionOn: serverSocket ] repeat ] ifCurtailed: [ self releaseServerSocket ] serveConnectionOn: listeningSocket "We wait up to acceptWaitTimeout seconds for an incoming connection. If we get one we wrap it in a SocketStream and #executeOneRequestResponseOn: on it" | stream socket | socket := (listeningSocket waitForAcceptFor: self acceptWaitTimeout) ifNil: [ ^ self log: 'Wait for accept timed out' ]. stream := ZnNetworkingUtils socketStreamOn: socket. [ [ [ self executeOneRequestResponseOn: stream ] ensure: [ self log: 'Closing stream'. stream close ] ] ifCurtailed: [ self log: 'Destroying socket'. socket destroy ] ] forkAt: Processor highIOPriority named: 'Zinc HTTP Server Worker' Each #acceptWaitTimeout seconds, 'Wait for accept timed out' is printed on the log and another accept/wait starts. This looping improves liveliness and responsiveness to other events. Sven
participants (3)
-
mkobetic＠gmail.com -
Schwab,Wilhelm K -
Sven Van Caekenberghe