On 24 Aug 2005, at 15:04, Trevor Warren wrote:
--- Chandrashekhar Mullaparthi
<[EMAIL PROTECTED]> wrote:
packets. The point to
note is (and you probably know this) that the choice
of transport
shouldn't be based on the raw speed you can achieve
but the
requirements your application has.
[snip]
My requirements are very simple. I need to make use
of a protocol that is low on cpu cycles and also
offers reliability.
You mean like eat your cake and have it too :-) Like someone else
pointed out, UDP is quite safe to use on LANs these days. We rarely
ever see UDP packets being discarded on a LAN these days. But if you
use UDP, you still need some application level protocol to make sure
your messages get through.
TCP proves itself on the
reliability front but is a high on cpu cycles.
Yes - but what kind of performance are you looking for? Have you
prototyped your application using TCP and checked if the thoughput it
offers is enough for you? If yes, it will save you the hassle of
implementing an application level protocol for ensuring reliability.
Remember this: premature optimisation is the root of all evil.
While on the UDP front i have performed some basic
tests. The raw througput in terms of bytes/s is almost
to an order 1/2 that of TCP for the same message size,
for the same no of clients over the same interval. As
of now...i need to find the which among TCP-UDP offers
the best throughput. Addressing Error handling at the
application layer and larger CPU cycle consumption is
the next step.
What do you think about this?. Am using simple
sendto() and recvfrom() calls for UDP while the normal
connect-send-recv calls on TCP.
I have never really compared the throughput between these two transport
protocols but I remember getting more throughput out of UDP by
increasing the size of the buffers used for receiving messages.
Chandru
--
http://mm.ilug-bom.org.in/mailman/listinfo/linuxers
