blocking i/o vs. non blocking i/o (performance)

[Andre Kelmanson]

Hi,
I'm writing a proxy application for rfb protocol (vnc), but i'm not
satisfied with it's performance. I'm using blocking i/o and the app
just read(...) from source and the write(...) to destination. The
performance diference 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 write(...) function.

thank you.
obs. sorry about my poor english.

[Jack Klein]

On 9 Oct 2003 21:03:12 -0700, an***@kelmanson.net (Andre Kelmanson)
wrote in comp.lang.c:

Hi,
I'm writing a proxy application for rfb protocol (vnc), but i'm not
satisfied with it's performance. I'm using blocking i/o and the app
just read(...) from source and the write(...) to destination. The
performance diference 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 write(...) function.

thank you.
obs. sorry about my poor english.

You need to ask in a newsgroup that supports your particular compiler
and operating system combination.

None of proxy, rfb, vnc, read(), write(), or non-blocking i/o are part
of the C language or its library, the topic here. C has no built-in
networking support at all. All such features are specific to the
implementation.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

[Derk Gwen]

an***@kelmanson.net (Andre Kelmanson) wrote:
# Hi,
# I'm writing a proxy application for rfb protocol (vnc), but i'm not
# satisfied with it's performance. I'm using blocking i/o and the app
# just read(...) from source and the write(...) to destination. The
# performance diference 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 write(...) function.

Non-blocking I/O can be useful if you are trying to do multiple simultaneous
reads and writes. If your process is doing a single read and write, that is
going to take the same amount of time whether your process suspends while
the kernel moves bytes or your process twiddles its thumb during that time.

--
Derk Gwen http://derkgwen.250free.com/html/index.html
No pleasure, no rapture, no exquiste sin greater than central air.

[Valentin Tihomirov]

You may perform a task in another thread in parallel to data transfer even
with blocking IO. You should detect the bottleneck youself to determine
whether you need a multitasking. May be it is your communication channel too
slow and non-blocking IO does not help.