[MUD-Dev] Re: TECH: Distributed Muds

[Caliban Tiresias Darklock]

On Wed, 2 May 2001 20:12:03 -0400, "Jon Lambert"
<tychomud at ix.netcom.com> wrote:
> Caliban Tiresias Darklock wrote:

>> True, but not under Windows. The Winsock concern is that an FD_SET
>> is actually an array of structures, which is a GREAT deal larger
>> than a bit vector.

> No it's an array of unsigned ints.  

Hmm, I was of the impression that the SOCKET datatype was actually a
type of structure pointer... not that I've really delved into the
internals. I shouldn't have to. :P

> Nevertheless the I/O completion ports is still a better alternative.

Assuming you're on Win NT/2K, which is the only place you can use
them.  Under Win 9x, your best available solution is overlapped I/O
with completion routines, and that's not really much of a
solution... in my looks at it, I haven't found any way to identify
WHICH socket cause the callback to be executed. The best way to do
that seems to be the definition of a C++ class with the callback
defined as a static function of that object, but then you don't have
the "this" pointer. I've thought about doing something stupid like
this:

  CMySocket::CMySocket()
  {
    this->CallBack(0,0,this,0);
  }

  static void CALLBACK CMySocket::CallBack(DWORD dwError,DWORD
    cbTransferred, LPWSAOVERLAPPED lpOverlapped, DWORD dwFlags)
  {
    static CMySocket *this=NULL;
    if(this==NULL) this=(CMySocket*)lpOverlapped;
  }

...but that's just BAD. It would probably *work*, but I really don't
like it. It's most likely a better solution to maintain an internal
class derived from WSAOVERLAPPED:

  class MYWSAOVERLAPPED: public WSAOVERLAPPED
  {
    public:
      CMySocket *which;
      // etc.
  };

  static void CALLBACK CMySocket::CallBack(DWORD dwError,DWORD
    cbTransferred, LPWSAOVERLAPPED lpOverlapped, DWORD dwFlags)
  {
    CMySocket *this=
      STATIC_DOWNCAST(MYWSAOVERLAPPED,lpOverlapped)->which;
  }

Since that's exactly how Windows manages all of its POINT/Cpoint and
RECT/CRect magic, among other things, that's probably the better
solution.

This doesn't get past the 100-socket limitation on Win 9x (unless you
modify the registry, which I may provide a user facility to manage),
but I don't think that's likely to be TOO much of a problem. I expect
to have three versions of my server: one for Win 9x, which can be used
to run a low-use system; one for Win NT/2K, which runs a larger
system; and one for UNIX, which also runs a larger system. All of them
will be binary-compatible in terms of configuration and DB, since the
network code will be the only real difference between them. The vision
I have here is that some people will run a small game on their home
computers, moving to cable modem or ISDN if bandwidth becomes an
issue; some will upgrade to NT to run a bigger one; and some will
actually offload it to a separate computer, running NT *or* UNIX, the
way you would a standard MUD.

> No the _traditional_ single-threaded select() design on Windows
> performs as well as that on Unix.

I've asked a lot of people about that, and you're the first one who
hasn't said "oh, it's OKAY, as long as performance isn't an
issue". None of them have been very forthcoming about what "an issue"
means. I've generally written that off as pointless elitism, since it
seems nobody has the vaguest clue what the hell I'm talking about when
I discuss the needs of the network layer. (Multiple persistent
connections which must be authenticated, may exist for several hours,
can be disconnected at any time, and will receive data of arbitrary
length at unpredictable intervals resulting in dynamically-generated
output.) Since it isn't essentially a variant of a web server, they
keep trying to turn it into one by suggesting I convert it to a
stateless protocol.

>> generally assume you will never have more than 64 sockets in an
>> FD_SET. ;)

> What do BSD and Linux assume to be the FDSETSIZE to be?  Both
> require you to #define FDSETSIZE should you want something else.

Don't know. I'm designing under Windows, because I don't think most
people have a UNIX server available where they can run arbitrary
processes. I *do* know that under UNIX, most MUDs don't bother to
define FD_SETSIZE to anything else, and happily support hundreds of
connections. Under Windows, however, there do exist stacks and service
providers which *ignore* anything past 64 sockets in a select() call,
no matter what FD_SETSIZE is. I'm not sure how common they are.

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