Subject: | |
From: | |
Reply To: | |
Date: | Thu, 29 Jun 2000 10:57:45 -0700 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
DBECKER complains:
> Not a good plan:
> At the ACCEPT, you actually get a socket port number, and this
> number is used to do the SEND / RECEIVE.
> If you want to carry on a conversation with multiple clients,
> multiple socket ports must be used.
>
> CREATEPROCESS cannot be used to carry on conversations because
> the file descriptors are lost when the new process is created!
RTFM under IPCGIVE and IPCGET as mentioned in my posting. They are the
NetIPC API routines which allow you to inherit the socket descriptors in a
son process created by CREATEPROCESS. Nowhere did I intend to imply that
using Berkeley sockets and CREATEPROCESS together was viable, only NetIPC
and CREATEPROCESS.
> What Gavin said is strictly true, except for implication that
> CREATEPROCESS can be used for file descriptors under
> certain circumstances for Berkley Sockets.
If you're using Berkeley sockets, then you're pretty much stuck with fork().
My point was that for the traditional MPE model, you use CREATEPROCESS and
NetIPC which does not require fork(). We did manage to write non-trivial
server systems on the 3000 before there was Posix you know :-)
> It may work well for NETIPC, but
> it sure as death, taxes and revenge doesn't work for Berkley Sockets.
Correct. If you want MPE, use MPE. There's an "MPE way" to do just about
everything you would want in writing a server application and in a way that
doesn't require any Posix stuff (the QWEBS web server being a good example).
If you want Berkeley sockets, then you're pretty much stuck with the rest of
the Posix world.
G.
|
|
|