[MUD-Dev] Socket Code

Stephen Miller stephen at pagemiller.com
Mon Aug 12 02:39:41 CEST 2002


Okay, I'm a bit new to this mailing list, I received my first mail
from it yesterday but had signed up two days before :).  I do know
how how much traffic is passed through or how one goes about
researching topics.  I also am unaware of what topics are
discussable or ones which shouldn't be addressed wtih the mailing
list.

After that preface, I'll give what I want to discuss a shot :).

Okay, I am not too concerned with mud portability as I think unix
and POSIX compatible operating systems are here to stay for awhile.
I am curious as to the best way to do socket code, and some ideas
were discussed with me.

  platform: Linux POSIX compliant
  language: c++
  compiler: g++

One was to have the traditional non-blocking select loop and to have
each socket put into an fd_set to be checked.

Another way was to have each connection be its own class and be
polled individually with either poll() or select() but again
non-blocking.

The third way seems more interesting and possibly better than the
other two, and I wanted to share it and see how you guys felt.  The
idea is that each player has a "queue" of things that represent
their commands to be processed.  The idea is either that the queue
is event based, or that the queue is just a list of commands that
the mud will execute the top of on each pass.  Either way, the point
of the connection is to do low level socket parsing of newlines to
get a sort of line by line thing to feed into the command
interpretter at some point.  Also removal of dangerous or unwanted
symbols is also done, as I understand it.

So the basic gist of this system would be to have a thread for each
connection which has a blocking select.  Each time the select
receives input on its socket, it grabs the input and if it should
have a line, it will lock (through semaphores or mutexes) the
respective shared memory player queue and push the new line onto the
back of the queue.  Then it unlocks and blocks again for more input.

The advantages of the second way seem to be...

  a) don't have to copy fd set all the time on each socket

  b) don't have to call select each pass

  c) don't have to match up file descriptors with classes.
 
  d) I get to play with threads (you cannot overlook this one! :p)

In any case, I also heard that this would scale better and be
"faster" with say...120 sockets, which doesn't really seem all that
important but better design for the long haul is something I believe
in.

Anyway, if you don't mind I'd like to hear thoughts on what would be
the best way, (not the hardest to code). :)

Thanks for your time,
Steve




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



More information about the mud-dev-archive mailing list