f



blocking i/o vs. non-blocking i/o

Hi,
I'm writing (in linux) a proxy application for rfb protocol (vnc), but
i'm not satisfied with  it's performance. I'm using blocking i/o and
my app just read(...) from source and the write(...) to destination.
The performance diference (over a 100mbits lan) between the client
directly connected to the server and the client passing thru the proxy
is very visible. Does non-blocking i/o solves my problem? Maybe the
problem here is the unnecessary(?) wait in (blocking) write(...)
function.

thank you.
obs. sorry about my poor english.
0
andre691 (2)
10/10/2003 12:48:30 PM
comp.unix.programmer 10848 articles. 0 followers. kokososo56 (350) is leader. Post Follow

4 Replies
881 Views

Similar Articles

[PageSpeed] 5

In article <29d62503.0310100448.4f09fdf2@posting.google.com>,
Andre Kelmanson <andre@kelmanson.net> wrote:
>Hi,
>I'm writing (in linux) a proxy application for rfb protocol (vnc), but
>i'm not satisfied with  it's performance. I'm using blocking i/o and
>my app just read(...) from source and the write(...) to destination.
>The performance diference (over a 100mbits lan) between the client
>directly connected to the server and the client passing thru the proxy
>is very visible. Does non-blocking i/o solves my problem? Maybe the
>problem here is the unnecessary(?) wait in (blocking) write(...)
>function.

I don't think switching to non-blocking is likely to help with performance.
The waits in read() and write() will simply be replaced by waiting in
select().

Note that write() only blocks if you're writing much faster than the remote
system can read, so that your local socket buffer fills up.  If the socket
buffer is not full, write() simply copies the data to the buffer and
returns immediately.

Using non-blocking I/O would allow you to keep calling read() while you
wait for the send buffer to clear out.  But you'll need to find someplace
to keep all the data you're reading until you're able to write it.

No matter what you do, your throughput is limited by how fast the receiving
system can take in data.  But that should also be the case when the client
and server are talking directly to each other.  If your proxy is impacting
performance significantly, it's probably something else.  Maybe the proxy
is advertising a smaller receive window than the real server (try
increasing SO_RCVBUF).

-- 
Barry Margolin, barry.margolin@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
0
Barry
10/10/2003 3:56:24 PM
"Andre Kelmanson" <andre@kelmanson.net> wrote in message
news:29d62503.0310100448.4f09fdf2@posting.google.com...

> I'm writing (in linux) a proxy application for rfb protocol (vnc), but
> i'm not satisfied with  it's performance. I'm using blocking i/o and
> my app just read(...) from source and the write(...) to destination.
> The performance diference (over a 100mbits lan) between the client
> directly connected to the server and the client passing thru the proxy
> is very visible. Does non-blocking i/o solves my problem? Maybe the
> problem here is the unnecessary(?) wait in (blocking) write(...)
> function.

    How do you do the reads exactly? You have two sockets, how do you decide
which one to call 'read' on?

    DS


0
David
10/10/2003 4:17:42 PM
On Fri, 10 Oct 2003 15:56:24 +0000, Barry Margolin wrote:

> In article <29d62503.0310100448.4f09fdf2@posting.google.com>,
> Andre Kelmanson <andre@kelmanson.net> wrote:
>>Hi,
>>I'm writing (in linux) a proxy application for rfb protocol (vnc), but
>>i'm not satisfied with  it's performance. I'm using blocking i/o and
>>my app just read(...) from source and the write(...) to destination.
>>The performance diference (over a 100mbits lan) between the client
>>directly connected to the server and the client passing thru the proxy
>>is very visible. Does non-blocking i/o solves my problem? Maybe the
>>problem here is the unnecessary(?) wait in (blocking) write(...)
>>function.
> 
> I don't think switching to non-blocking is likely to help with performance.
> The waits in read() and write() will simply be replaced by waiting in
> select().

 You replace blocking in _either_ read or write, with select/poll/etc.
which emulates blocking in _both_.
 This can be very significant when one would block and the other wouldn't.

> Note that write() only blocks if you're writing much faster than the remote
> system can read, so that your local socket buffer fills up.  If the socket
> buffer is not full, write() simply copies the data to the buffer and
> returns immediately.

 This is a simplification of half of the story. It assumes you are using
much less than the OS/ethernet/etc. buffer sizes almost all the time, and
possibly for very short periods you get a burst of data.
 If however you have data moving close to the buffer size for a longer
period, then _any_ delay is going to backup on the read and the write.

> Using non-blocking I/O would allow you to keep calling read() while you
> wait for the send buffer to clear out.  But you'll need to find someplace
> to keep all the data you're reading until you're able to write it.

 Application memory is _much_ cheaper than kernel socket buffer memory.

> No matter what you do, your throughput is limited by how fast the receiving
> system can take in data.

 No, in this case, it's limited by how fast you receive the data from the
client and how fast you can send the data to the server. Which is often
very different.

-- 
James Antill -- james@and.org
Need an efficient and powerful string library for C?
http://www.and.org/vstr/

0
James
10/11/2003 8:09:39 PM
On Fri, 10 Oct 2003 05:48:30 -0700, Andre Kelmanson wrote:

> Hi,
> I'm writing (in linux) a proxy application for rfb protocol (vnc), but
> i'm not satisfied with  it's performance. I'm using blocking i/o and
> my app just read(...) from source and the write(...) to destination.
> The performance diference (over a 100mbits lan) between the client
> directly connected to the server and the client passing thru the proxy
> is very visible. Does non-blocking i/o solves my problem? Maybe the
> problem here is the unnecessary(?) wait in (blocking) write(...)
> function.

 Possibly, see...

http://www.and.org/texts/network_io.html
http://www.and.org/texts/network_io.html#doublemove

....the text at second link is specifically about the problem you _may_ be
having, where you can lower the total IO to the minimum of the input or
the output.

 Also, is there only ever a single connection through the proxy? If not
then any blocking read or write on a single connection will be blocking
all other connections. If this is the case then moving to non-blocking IO
will pretty much be guaranteed to make things better.

 It's also possible that you've introduced some latency, either through
the extra network connections or internal organization of your proxy code
(for instance you may be dealing badly with large amounts of data).
 If converting to non-blocking IO doesn't seem to help you much, then you
should try and qualify what is going wrong, Ie. is it sustained throughput
that is lower, or is there significantly more latency? (I'd guess the
later, but numbers talk...)

-- 
James Antill -- james@and.org
Need an efficient and powerful string library for C?
http://www.and.org/vstr/

0
James
10/11/2003 8:15:07 PM
Reply: