[lkml]   [2002]   [Jul]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: more thoughts on a new jail() system call
Thunder from the hill <> 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
(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

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

[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 --
* ^From: .*james@and\.org
 \ /
  Last update: 2005-03-22 13:27    [W:0.054 / U:0.228 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site