Messages in this thread | | | Subject | Re: more thoughts on a new jail() system call | From | James Antill <> | Date | 19 Jul 2002 03:48:27 -0400 |
| |
Thunder from the hill <thunder@ngforever.de> writes:
> Hi, > > On 19 Jul 2002, James Antill wrote: > > The more general spelling is FIONREAD, and I generally find that only > > crap network applications need to use it. Good ones just try and read > > a largish amount of data into a buffer. > > That doesn't matter as long as you haven't got any idea on how much data > will be read. Especially relaying between two completely different hosts, > possibly unknown protocols, you don't have a chance to know who will send > next. Without TIOCINQ you'll almost be shot if you have received lots of > lots of stuff from the client and expect any response from the server. You > just won't get it. > > Give me another version of the appended piece of code that won't use > ioctl, and I'll consider an acknowledgement.
Hey, why not I'm bored[1] and have half an hour...
Here it is, both libraries needed can be got from http://www.and.org/ (I know socket_poll still requires gnome-config ... I'll get around to changing it to pkg-config soonish).
Here's a quick list of differences[2]...
1. Your version can _lose data_ when not all of the data from recv is sent down send.
2. Your version _loses data_ when '\0' characters are in either stream.
3. Your version can easily get stuck doing work for just one direction, while the other direction is ignored.
4. Your version has to use usleep() because you've done manual polling using ioctl(FIONREAD). Welcome to latency hell.
...points 1 and 3 will heavily suggest some kind of buffering mechanism and non-blocking read/write calls. That means you'll end up only using ioctl() for a ready/error state indicator. To fix point 4 you'll need to use poll()/etc. to get a ready/error state. Thus your program now being not too bad ... won't need to use ioctl(FIONREAD).
[1] But not bored enough to write everything without using some decent libraries ... so sue me.
[2] There are a couple of differences in error reporting, Ie. mine reports "read (*): No space left on device" when one of the connections is closed ... yours presumably fails from ioctl(). If I cared the code would be much different and be able to accept multiple connections etc. but I don't.
[unhandled content-type:application/octet-stream] -- # James Antill -- james@and.org :0: * ^From: .*james@and\.org /dev/null
| |