Well, TCP does not actually guarantee the data will make it to the remote, what TCP guarantees is notification of probable non-delivery.
rick jones
-- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
Neither does the TCP re-establish connection from the client to the server if the server is rebooted, powered up, hardware replaced, switch to a redundant unit (and if symbolic addressing is used, change of IP address).
You still need to build an additional layer to handle these events and re-establishing connections for non-attended 24/7 operation.
Indeed. In the parlance of the seven-layer (or nine depending on one's point of view -
rick jones
-- The glass is neither half-empty nor half-full. The glass has a leak. The real question is "Can it be patched?" these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
In comp.protocols.tcp-ip Paul Keinanen wrote: (snip)
UDP will do some of those. The UDP implementation of NFS is pretty good at surviving server reboots and continuing on as if nothing changed. I believe the TCP implementations automatically reconnect, transparent to the user.
-- glen
If the TCP implementation of NFS will perform the reconnection, then that is the feature of the NFS, not the TCP.
, t d
ely
Good link !
out
tthe
be
uch
Thx for your suggestions.
Karthik Balaguru
The TCP server forks a new process (which is very fast, as nothing needs to to copied) to handle a new connection. If you want fast data transfer, then you need to let the TCP applications (on both sides) to buffer the data.
Normally the network stat uses a slow-start algorithm to make sure collisions do not degrate the network.
UDP provides no way to detect collisions, if used, can cause a network collapse - where the bandwidth drops to zero and never recovers because the applications keep trying to consume all of the bandwidth.
If the kernal is overloaded, it can drop UDP packets from the queue before it sends them out.
Also - if A sends to B, and B replied to A, how does B know that A got the reply or not?
And if the transaciton is large (multi-packets), you need to use multple packets. And then you have to keep track of these, and reassemble them.
TCP is usually used for services that require a large amount of interaction between the client and server, and state that must be maintained for the duration of the connection. Forking a process or spawning a thread provides an easy way to maintain that state, and keep other connections from interfering. And since the connection is likely to be maintained for a significant period of time, the overhead of forking a process is usually negligible.
UDP is generally used for simple request/response protocols, where each packet is independent and state doesn't need to be maintained. Speed is often of the essense, so having to fork a process for each request would slow things down noticeably.
There are exceptions, though. If a server handles hundreds or thousands of concurrent connections, forking so many processes is likely to overload the system. Thread pools are often used for these types of servers.
-- Barry Margolin, barmar@alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group ***
Some things need to be copied, like file descriptors, but nothing big. Still, forking takes considerably more overhead in time and space than managing the context yourself.
-- Gemaakt met Opera's revolutionaire e-mailprogramma: http://www.opera.com/mail/ (remove the obvious prefix to reply by mail)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.