Nice work on the socket code!!

[Steve Barber]

Congratulations are in order to Bradley Smith and Alex Crain for
their work on the socket code!  Nice work, guys!

However,
(I'll bet you knew there had to be a catch, right?  :-)

In the process of porting a multiplayer game that uses sockets to
run on the 3B1, I discovered what appears to be a lack in the
current (1.2) socket code - specifically the select call.

NOTE: I'm new to sockets and learning as I go, so bear with me
here.  If I'm out of line, I'm sure you'll let me know...  :-)

The symptoms are as follows:  the driver program gets started up in
the background.  It creates a socket, binds it to a filename in /tmp,
then does a listen(s, 5) on it.  The client program (one per player)
then creates a socket, binds it to the filename, and does a connect(2)
call to connect to it.  It hangs about here someplace until an alarm
goes off.

I need to do some more testing, but this is what appears to be the
problem:

The select(2) call that the driver runs is not detecting the connection
requested by the client program, therefore it never calls accept(2).
According to a man page I checked on a BSD system (accept(2), specifically),
select is supposed to set a flag in the read bitmask if there is a
connection pending.  Currently it doesn't look like this functionality
is provided in the 1.2 version of select.

If anyone in the know would like to comment on the validity of my
diagnosis, as well as any possible workarounds, I would appreciate it.
As I said, this is a port from a game that works on a BSD system and
I'm more than 99% sure that this is not a logic error in the game itself.
I know Bradley and Alex are busy, so I'm asking the net to see if anyone
knows the code well enough to help me out.

BTW: I don't mind coding a fix to the socket code, but I'm a little queasy
about messing with the driver code without some idea of what the right
thing to do is!
-- 
--**-Steve Barber----steveb at shade.Ann-Arbor.MI.US----(cmode)-------------------