sean@ms.uky.edu (Sean Casey) (06/13/88)
I'm writing a real-time game program where a server multiplexes input
from a number of clients. Most of it works pretty well (thanks matt@oddjob),
but I can't seem to pick up Out Of Band messages with select().
I'm calling select() with a read fdset and an exception fdset. The time
value is infinite (NULL). When data comes in, the select returns and all is
well, but if a client sends an OOB, the select does not return as it should.
In other words, it seems to be ignoring OOB messages. According to all the
documentation I can find, the only exceptional condition for sockets is out
of band transmissions, and therefore I assume that if all is well, an OOB
sent will cause the select to return.
Did I assume wrong? I can code around it, but OOB messages seem to be an
ideal way of sending a "flush input buffer" command. Perhaps there's
something I need to be doing.
I did try setting the process group and trapping SIGURG, and sure enough,
the OOB messages are getting there. I just can't make select recognise
them.
Anyone know what I might be doing wrong?
Sean
--
*** Sean Casey sean@ms.uky.edu, sean@ukma.bitnet
*** The Empire Defenestrator {rutgers,uunet}!ukma!sean
*** ``I'm not gonna mail it, YOU mail it. I'M not gonna mail it... Hey! Let's
*** send it to Rutgers! Yeah! They won't mail it. They return everything.''roy@phri.UUCP (Roy Smith) (06/13/88)
sean@ms.uky.edu (Sean Casey) writes: >I can't seem to pick up Out Of Band messages with select(). I'm not surprised. I sat down a while ago to do a rewrite of the BSD rlogin client (which depends on OOB data) to run as a native suntool (as opposed to having to do shelltool/csh/rlogin). Anyway, what I discovered is that 1) the BSD OOB documentation is sketchy and incomplete (and possibly wrong) and 2) the whole concept behind the BSD OOB code is horrible. I'm not sure how the original "framers of TCP" intended OOB to work, but I can't believe it's how Berkeley implemented it. Possibly the problem was that Berkeley was trying to make OOB work on XNS as well as TCP? Disclaimer: I'm far from a networking guru; I fully expect better answers to come from the regular network wizards. Also, my answer is based on my experiences with MtXinu 4.3BSD/NFS on a vax and SunOS-3.2 (a 4.2 derivitive, with some 4.3isms thrown in). > I'm calling select() with a read fdset and an exception fdset [...] if a > client sends an OOB, the select does not return as it should. One possible problem is that IB (in band) and OOB data seem to get stacked, and the reception of the SIGURG and/or select(exceptionfd) returning is done when the networking software first finds out that OOB data is pending. Unfortunately, depending on how much IB data is in the input queue, you may not yet be able to read the OOB data. This seems pretty bogus to me and may be part of your problem. One way around it is to make sure that you read any queued IB data (do non-blocking reads until you get EWOULDBLOCK) before trying to read the recv() the OOB data. Another problem with OOB data is that, as far as I can tell, the concept of "at the mark" is very poorly defined. If you do the following in a server: fd = socket(); for (1) { select (fd for exceptions); recv (fd, MSG_OOB); }; and have the client send() a single OOB datum, the server will loop forever reading the same OOB message as if you had given MSG_OOB|MSG_PEEK. As mankin@gateway.mitre.org put it in a recent letter to me on this subject, "The trick is that the system signals the mark both before and immediately after the octet has been read. The mark signal only goes off when data after the mark is read from the receive queue. The mark is, in effect, on both sides of the urgent byte" I cannot find any reason why such behavior should be considered the correct way of doing things and can only conclude that OOB data, while a very nice concept, is broken enough in BSD as to be virtually unusable. In my case, I didn't have a choice; I had to interact with an existing server which use OOB. If you have the freedom to design the entities on both sides of the connection, I would say to stay away from OOB if at all possible. -- Roy Smith, System Administrator Public Health Research Institute 455 First Avenue, New York, NY 10016 {allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net