On 24 Aug 2005, at 15:04, Trevor Warren wrote:
--- Chandrashekhar Mullaparthi chandrashekhar.mullaparthi@t-mobile.co.uk 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