MC concurrency performance?

[Dar Scott]

On Tuesday, September 10, 2002, at 01:01 AM, Alex Shaw wrote:

> But what happens to other connections which try to access a server 
> app port while it's processing a request?
> Does "accept on port with message" buffer those or do they get 
> dropped and the client must "open socket" every few millisecs?
...
> These are UDPs in particular I'm talking about now, is this a 
> system thing or should I be worried that the client will run out 
> of ports? :)

Use the accept command.  This will generate a callback for each new 
UDP "connection".  The callback will have the contents of the 
datagram that initiated things and a socket identifier for a new 
UDP "connection".  This is separate from the socket id for the 
listening connection, that is, the one for the accept.

If you have only a simple service and need only send back a single 
response, you might do that in the callback.  Be sure to close the 
"connection".

If there is a dialog, optionally send back a response and then pass 
the work on with either a "send in time" or a udp read with a 
callback.  The idle time clears things for receiving the next 
"connection".  One simple approach that might work would be to have 
all the dialog work done in the read callbacks.  You can have 
either a single callback handler that checks the state of the 
discussion or several handlers with the handler selected by the 
callback specified in a particular read.  (The limitation is that 
this does not do anticipatory work or delayed response work; if you 
have a complex dialog, you might want to also do "send in time" to 
get work done while waiting for a response.)

The only "connection" info you have in the read callback is the 
socket ID.  You will have to manage all other "connection" state 
info through that.

If you want to limit the number of "connections" keep track of a 
count.  Increase it with the accept callback and decrease it near 
the close of the connection created with the accept callback.  If 
the count gets above some level, the accept callback should simply 
close the "connection" and exit immediately.  (If you worry about 
attack, also turn off the accept for a while.)

I put "connection" in quotes because there is no real "connection" 
in UDP at the tcp/ip protocol level, it is a convenience.

As with TCP, within UDP, "connections" are identical if the all 
four of local address, local port, remote address, and remote port 
are the same.  Datagrams are routed to the either the accept 
connection if new or to an established "connection" if that 
exists.  Ports will be assigned to the "connections" and there are 
lots available in a typical system.

You will eventually need to handle timeout conditions if there is a 
dialog.  Handle that the same way as other state transitions.

Dar Scott