Attached is some code I wrote a while ago based on advice that ConnectionQueue and SocketStream are correct starting points. I am a big believer that network code should do what it is told until it told to stop; timeouts should be in the hands of the user, application programmer or server administrator, not decided by the socket layer.
________________________________________ From: [email protected] [[email protected]] On Behalf Of [email protected] [[email protected]] Sent: Wednesday, January 12, 2011 1:13 PM To: [email protected] Subject: [Pharo-project] Socket question (Was Re: Xtreams up to date) I started looking at the Socket failures that I can reproduce and I can't wrap my head around the SocketReadingWritingTest>>setUp. Based on what I know about TCP sockets it doesn't make sense to me. AFAIK to get both ends of a connected TCP connection (lacking a socketpair call) I need 3 sockets. A listening socket, a client socket (doing connect) and finally the server socket that comes out as a result of accept on the listener. So I'd expect to see something like this in the setUp: | data input output listener socket1 socket2 process sync | Socket initializeNetwork. sync := Semaphore new. listener := Socket newTCP. listener listenOn: 9999. process := [ [ socket1 := listener accept ] ensure: [ listener close ]. sync signal ] fork. socket2 := Socket newTCP. socket2 connectTo: (NetNameResolver localHostAddress) port: 9999. sync wait. output := socket1 reading. input := socket2 writing. Surprisingly, the above doesn't work, while many of the Socket tests seem to pass for me despite my brain telling me that it can't possibly. Can anyone shed some light on this for me ? Thanks, Martin
NetworkSmokeTestCase.st
Description: NetworkSmokeTestCase.st
