Bob Pendleton wrote:
You have mentioned that the blocking occurs because of a slow client.
Have you verified that? Is it possible that the slow down is the result
of buffer exhaustion in the OS or network traffic at another location in
the network? Have you seen this problem occur on a LAN? Or only on the
Internet?
I really don’t know the exact cause of the blocking. But I don’t see why
exactly it’d be necessary to work this out. The documentation for send()
says that it can block indefinitely. I don’t see how anyone can see it
as acceptable for their program to have the documented potential to
block indefinitely, whatever the cause.
If you had a non-blocking send()
Actually I’d prefer to have access to a select() wrapper that allows me
to determine if sockets are ready to write to without blocking.
Non-blocking send() would work too though.
I was under the impression that it was not, in general, possible to
implement a select() that could guarantee that a send will not block.
The conditions that the select() calls at the time you call it are not
guaranteed to be the conditions that exist when you call send(). Nor,
can the select() call know how much data you are going to send() or what
the state of the network will be at the time of the send().
It sounds like you really need a non-blocking send(). You could
implement this with threads, but you would need to use a thread pool and
allocate a thread per pending send() to ensure that the server never
blocks. Of course, if it was a network problem then, then in some cases
the library would have to block because it couldn’t allocate enough
threads to handle all the pending send() calls.
I admit that this problem is something I punted in my net2 library. My
testing never showed send() calls blocking for long periods of time so I
didn’t worry about it.
Thanks for the information, I may have to rewrite parts of my library.
Bob PendletonOn Thu, 2004-07-01 at 10:25, David White wrote:
how would you use it? I assume you
would look for the ewouldblock/eagain messages and queue the output
until you finally get to send the message? If so, how long do you hold
it in the queue and how much output are you willing to queue before you
declare the client too slow to play and disconnect it?
You’d set a limit, and disconnect the client once the limit is reached.
There’d be various methods of setting a limit, the most obvious being an
amount chosen after testing, and probably configurable using command
line parameters.
Even having no limit, and queuing data indefinitely until the client can
take it would be much better than having the potential for a connection
to block indefinitely and lock up the server.
David White
Lead Developer
Battle for Wesnoth (http://www.wesnoth.org)
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-------------------------------------+