lkml.org 
[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
From
Date
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
\
 
 \ /
  Last update: 2005-03-22 13:27    [from the cache]
©2003-2011 Jasper Spaans