[MUD-Dev] Re: TECH: Distributed Muds

[Jon Lambert]

Derek Snider wrote:
> From Jon Lambert, April 27, 2001 3:39 PM

> First of all, I find it difficult to put too much faith in the
> opinions of Windows programmers of how to do socket programming
> under UNIX.


Most of the persons involved in the creation of the winsock
specification and subsequently the winsock lame list are the same who
created the BSD sockets spec and implementation.

But then I can generalize as well...  I wouldn't put too much faith in
mud programmers on how to to sockets programming anywhere.

E.G. I found this in a number of Unix mud codebases which I will not
name.

  if (recv(pConnection->sockfd, &c, 1, 0) == -1)

>> 1) Calling select() with three empty fd_sets and a valid TIMEOUT
>> structure as a sleazy delay function. Inexcusably lame.  Reason:
>> The select() function is intended as a network function, not a
>> general purpose timer.  Alternative: Use a legitimate system timer
>> service.

> As I mentioned before, and nobody responded... UNIX does have a high
> granularity delay function -- usleep().  I also mentioned that it
> didn't seem all that accurate when I experimented with it about five
> or six years ago, and that select() appeared to be a better
> alternative at the time.

Neither will have a granularity of less than the scheduler time slice,
which is 10 millisecs (on a non-rt Unix).  I know usleep() works as
advertised on FreeBSD and on Slackware Linux.  That is it specifies
the _minimum_ time to sleep.  If you're using select() outside the
context of network code, IMO I think it's sloppy.  If one needs a
granularity of less than 10 millisecs, one should be running some sort
of realtime OS.

>> 23) select(). Self abusively lame.

>> Reason: Consider the steps involved in using select(). You need to
>> use the macros to clear the 3 fd_sets, then set the appropriate
>> fd_sets for each socket, then set the timer, then call
>> select(). Then after select() returns with the number of sockets
>> that have done something, you need to go through all the fd_sets
>> and all the sockets using the macros to find the event that
>> occurred, and even then the (lack of) resolution is such you need
>> to infer the event from the current socket state.

> The fd_sets are bitstrings.  With 1024 file descriptors (for
> example) that is 128 bytes per set.  To clear 384 bytes, and to
> check the bits on 384 bytes is hardly CPU intensive.

> If it is so much more efficient to loop through all the descriptors
> yourself with send() and recv(), then wouldn't we be doing that
> instead?

That certainly isn't an alternative I would seriously consider.  The
problem is there just aren't very many good alternatives without a
kernel change.  I think true scalability won't be achieved until
sockets are treated in the same way as attached real-time devices that
_signal_ the OS.

--
--* Jon A. Lambert - TychoMUD        Email:jlsysinc at ix.netcom.com *--
--* Mud Server Developer's Page <http://tychomud.home.netcom.com> *--
--* If I had known it was harmless, I would have killed it myself.*--




_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev