karthikbalaguru
wibbled on Saturday 20 February 2010 13:10
> While reading about the various designs, interestingly i
> came across an info that the design of TCP servers is
> mostly such that whenever it accepts a connection,
> a new process is invoked to handle it .
Not generally true these days - used to be the method of choice, see
below...
> But, it seems that in the case of UDP servers design,
> there is only a single process that handles all client
> requests. Why such a difference in design of TCP and
> UDP servers ? How is TCP server able to handle
> large number of very rapid near-simultaneous connections ?
> Any ideas ?
>
First I recommend signing up to O'Reilly's Safari books onlinbe service - or
buy some actual books. There are some excellent O'Reilly books specifically
on TCP/IP.
In the meantime, speaking generally (without embedded systems specifically
in mind):
TCP = reliable stream connection oriented protocol. No worrying about
sequences, out of order packet delivery, missed packets - except in as much
as your application needs to handle the TCP stack declaring it's given up
(exception handling). Some overhead in setting up (3 way handshake) and
closedown.
UDP = datagram protocol and your application needs to worry about all the
rest above, if it cares. But very light - no setup/closedown.
Regarding TCP service architechture, there are 3 main classes:
1) Forking server;
2) Threaded server;
3) Multiplexing server;
1 - simplest to program, heaviest on system resources. But you can
potentially (on a real *nix system) simply write a program that talks to
STDIN/STDOUT and shove it behind (x)inetd and have a network server without
a single line of network code in your program. Perfectly good method for
light load servers where latency is not an issue.
2 - Popular - little harder to program, much more efficient, assuming your
OS can handle thread creation more lightly than process creation.
3 - Very efficient. One process maintains a state for all connections, often
using event methodology to call service subroutines when something
interesting happens (eg new connection, data arrived, output capable of
accepting data, connection closed). Sounds horrible, but with an OO
approach, very easy to get your head around. Now bearing in mind that
anything in OO can be bastardised to a handle and an array of struct which
holds the equivalent data that an OO object would, this could be a very
suitable method for emebedded systems where C may be the language of choice
and there may be no OS or only a very simple one that doesn't map well.
Now, doing 3 wouldn't be so far different to doing it all in UDP *except*
you now have to care about packet delivery unreliability - as you can get a
variety of stacks for many embedded systems, why not let someone else's hard
work help you out?
--
Tim Watts
Managers, politicians and environmentalists: Nature's carbon buffer.
|
|
|
