On Wed, 11 Nov 1998, Andreas Raab wrote: 

> Folks,
> 
> John Maloney pointed me to a very instructive problem within the Win32
> socket implementation. Without going into details, let me say that the
> current scheme of Squeak accepting only a single incoming connection does
> not work reliably in the threaded Win32 environment used in Squeak.

I pointed this out to John, I guess he pointed it out to you.
I had trouble even accepting any second connection.

> I have been thinking about a solution to the problem, and found one, 
but I
> would like to have an opinion from your side about this. What I'm planning
> to do is that each server socket (e.g., started with a listenOn: port)
> will introduce a separate thread in the VM handling the incoming
> connections, but FOR THE LIFETIME OF THE CURRENT SQUEAK SESSION.

The lifetime should be that of the socket.  I.E. kill the OS thread when 
the serverSocket
is closed (or ungracefully destroyed). Obviously, sockets can't 
meaningfully outlive VM sessions.
Otherwise you will chew up your thread pool... blech.

> Thus,
> whenever you're doing a listenOn: port after the first one on this
> particular port the only thing that happens is that the already running
> thread get's a notification that there is some interest in handling the
> next connection.

I would have #listeOn:  be a primitive that calls the listen() function,
and #accept should wait on the parent socket's activity semaphore
untill incoming connection arrives.  Accept should answer the child socket.

BTW, the external object registry (Smalltalk registerExternalObject:) is 
not thread-safe.
This needs to be fixed for robust server applications.

> This has two interesting consequences. First of all, it would allow to
> handle more than one incoming connection. So, for instance, the following
> sequence would perfectly work:
> 
>   "... usual init stuff goes before..."
>   server1 listenOn: 12345. "<- This starts the VM level thread"
>   client1 connectTo: localHost port: 12345.
> 
>   "Now comes the fun!"
>   client2 connectTo: localHost port: 12345. "<- will immediately connect"
>   server2 listenOn: 12345. "<- will get the connection from client2"

I think it is important for writing robust servers to separate listen and 
accept, so the client should have it's connection established only after the 
server does an accept.

For more info, check out

	TCP/IP Illistrated Vol 1
	W. Richard Stevens
	ch 18.11, TCP Server design

> I consider the above sort of good news.
> 
> However, there are two downsides of this. First of all, there is a running
> OS thread for every port that's been served in the current session.

This beats Unix's select...

> Also,
> if clients don't check for timeout conditions they could wait forever
> without getting any response from the server (see above, if server2 would
> not be started, client2 would get no response at all from the server it's
> been "connected" to). So, the major question is, how likely is it to have
> "temporary serving ports", e.g., sockets that are only used for serving on
> a particular port just once - and then never again? I don't think that
> this is likely but I would like to get an opinion from folks that use the
> Squeak networking stuff more than I.

I have done a fair amout of client/server work in VW.
I had trouble using squeak because of the problems we are now discussing.
I think that timeouts are certainly better handled by image code than by 
VM code,
and usually better handled in a separate monitor (Smalltalk image) process.

One problem with using squeak processes is that processes waiting on
a semaphore do not create a context (stack frame).  This makes debugging,
monitoring, deadlock detection, and all other reflective niceties very 
krufty. I outlined a solution for this to John.

> Thanks for any responses,
>   Andreas

Sure thing,
	Mike

mklein at alumni.caltech.edu