The usocket FAQ suggests that the way I should do this is by reading from a socket-stream
and checking for an end-of-file
result. That works in the case where I've got one thread active per socket, but it doesn't seem to satisfy for the case where I'm trying to service multiple sockets in the same thread.
Consider something like
(defparameter *socket* (socket-listen "127.0.0.1" 123456))
(defparameter *client-connections*
(list (socket-accept *socket*)
(socket-accept *socket*)
(socket-accept *socket*)
(socket-accept *socket*)))
For this exercise, assume that I've actually got four clients connecting there. It seems like the way to go about serving them from one thread is something like
(wait-for-input *client-connections*)
(loop for sock in *client-connections*
for stream = (socket-stream sock)
when (listen stream)
do (let ((line (read-line stream nil :eof)))
(if (eq line :eof)
(progn (delete sock *client-connections*)
(socket-close sock))
(handle sock line))))
Except that this won't work, because a disconnected socket still returns nil
to listen
, and an attempt to read
from an active socket with no messages will block but wait-for-intput
returns immediately when there's a closed socket in the mix, even when no other socket has a message ready (though it seems to fail to specify which sockets caused it to return).
In the situation where no client has spoken in a little while, and third client disconnects, there doesn't seem to be a good way of finding that out and closing that specific socket connection. I'd have to read them in sequence, except that since read
blocks on no input, that would cause the thread to wait until the first two clients both sent a message.
The solutions I've got in mind, but haven't found after some determined googling, are (in descending order of preference):
- A function otherwise equivalent to
listen
that returnst
if a read on the targets' stream would return anend-of-file
marker. (Replacinglisten
above with this notional function would let the rest of it work as written) - A function otherwise equivalent to
wait-for-input
that returns a list of closed sockets that cause it to trip. (In this case, I could iterate through the list of closed sockets, check that they're actually closed with the suggestedread
technique, and close/pop them as needed) - A function otherwise equivalent to
wait-for-input
that returns the first closed socket that caused it to trip. (As #2, but slower, because it prunes at most one inactive connection per iteration) - Keeping track of how long its been since I've received input from each socket connection, and closing them out regardless after a certain period of inactivity. (Which I'd probably want to do anyway, but doing just this would potentially keep a bunch of dead connections around much longer than necessary)
- A function that attempts to
read-char
from a stream with an instant timeout, returnst
if it encounters an:eof
, andunread-char
s anything else (returningnil
after either timing out or unreading). (Which is a last resort since it seems like it would be trivially easy to break in a non-obvious-but-lethal way).
Also, if I'm thinking about this in precisely the wrong way, point that out too.
It turns out that the thing I mention as Option 2 above exists.
wait-for-input
defaults to returning the full list of tracked connections for memory management purposes (someone was reportedly very concerned aboutcons
ing new lists for the result), but it has a&key
parameter that tells it to just return the connections that have something to say.is what I was looking for there. This returns all the ready connections, not just ones that are going to signal
end-of-file
, so the loop still needs to handle both cases. Something likeshould do nicely.