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 _______________________________________________ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
