[MUD-Dev] Re: lurker emerges
Chris Gray
cg at ami-cg.GraySage.Edmonton.AB.CA
Sun Aug 9 19:15:50 CEST 1998
[James Wilson:]
>I for one have only a vague idea of what this technique consists of.
>Could you maybe give some details, or a url describing it? Why would
>one need non-blocking i/o if select() tells you which sockets are
>ready for reads and writes? That is, assuming you bound the size of
>your output chunks appropriately, if the socket's ready for i/o shouldn't
>blocking be moot?
The system only has a limited number of buffers that it will use for
messages it has accepted, but cannot yet deliver. So, it is possible
for a socket to be marked as available for output, but the system still
doesn't have enough buffers to accept the entire message you are
trying to write to it. This could be because you have a very large
message, or perhaps because some other process grabbed all the socket
buffers first. More likely, it could be because a bunch of packets
arriving over your network connection has filled them up. So, making
all sockets non-blocking means that you will never block on a send
or receive, and so will maximize your throughput. The system may have
some resource allocation strategies such that it won't allocate too
many buffers to one IP address or something.
>I am curious as to how one could speed up this process - can you
>avoid doing a search through the set of all active sockets to find
>those that are ready for i/o? Could you split up the fd_sets somehow
>to bound the number that would have to be checked? It seems like
>when one gets to thousands of simultaneous connections this
>could become a bottleneck.
This should be in the archives, from about 2 weeks back. One point
was that if you have a native implementation of the 'poll' interface,
then you can use multiple threads, each with a subset of the sockets,
and thus cut down on the order-of-magnitude of the fd scans that both
you and the system have to do.
Another approach is possible if you have a custom protocol (i.e. not
just telnet). You can use UDP sockets instead of TCP sockets (which
requires you to handle the non-reliability), and then just have one
socket, and use 'sendto' and 'recvfrom' over it.
--
Chris Gray cg at ami-cg.GraySage.Edmonton.AB.CA
More information about the mud-dev-archive
mailing list