Re: sockets /network programming Requirements

From: kensai_at_[hidden]
Date: 2001-07-30 17:37:17

--- In boost_at_y..., williamkempf_at_h... wrote:
> --- In boost_at_y..., "Greg Colvin" <greg_at_c...> wrote:
> > From: <williamkempf_at_h...>
> > > ...
> > > * The "must be portable" requirement may prove more than 
vexing. 
> Unix
> > > programmers rely heavily on select(), while Windows programmers 
> can
> > > only make very limited use of this and rely almost completely on
> > > asynchronous routines not available to Unix programmers.  The
> > > simplest way to insure portability is to support only blocking 
i/o
> > > with very limited ability to check for available data, but this 
> can
> > > severely complicate coding.  A possibly better solution is to 
> provide
> > > a callback mechanism similar to the asynchronous routines in 
Win32
> > > that do not rely on Win32 specific WndProc mechanisms.  (I never
> > > understood why I/O was tied to a GUI object in Win32 
asynchronous
> > > routines.) Such an interface could be coded portably using 
> threads on
> > > any platform, though the design will be much more complicated.
> > > ...
> > 
> > It is possible to paper over these Unix/Windows differences, 
since 
> most
> > all the available java sockets implemenations do so.
> > 
> > In our implementation of the java socket classes we use poll() 
> rather
> > than select() on Unix, and WaitForMultipleObjects() on Windows.  
We
> > don't wait for a Windows GUI object, but instead for the hEvent 
> that we associate with the socket with WSAEventSelect().  The code
> > belongs to
> > Oracle, so I can't post it, but there are other more open java
> > implementations one could study.
> 
> I guess I wasn't overly specific.  This is the "very limited 
ability 
> to check for data" I mentioned.  In fact, this can be done with 
select
> () on Win32 to keep the implementation more uniform across 
> platforms.  The drawbacks are that this select() mechanism is valid 
> only for sockets.  Unix users mix socket, file, pipe and keyboard 
> descriptors in a single call to select() to wait for multiple I/O 
> events, but the Win32 select (and the WSAEventSelect) will only 
work 
> for socket descriptors.

The closest match in Windows would be to use i/o completion ports.  
It's inextricably linked to threading, but completion routines work 
for both socket and file operations (and perhaps others as well -- 
you can explicitly signal an operation as complete) and are quite 
similar to poll().  In addition, they remove the 64 event limitation 
of WSAWaitForMultipleEvents.

Still, this is a far cry from BSD sockets.  Settling on a portable 
interface might be difficult... but if the library is buit on select
() no Windows programmers may use it (I probably wouldn't).

Sean