Efficient methods
in [Linux Networking]
|
Prev: 'netstat' and '-f inet' option
Next: WPE for linux
From: Jorgen Grahn on 20 Feb 2010 16:22 ["Followup-To:" header set to comp.protocols.tcp-ip.] On Sat, 2010-02-20, Paul Keinanen wrote: > On Sat, 20 Feb 2010 08:15:13 -0800 (PST), karthikbalaguru > <karthikbalaguru79(a)gmail.com> wrote: > >> >>Agreed, but the query is about the design of the >>TCP server and the UDP server. In TCP server .... >>Will the TCP server get overloaded if it creates >>a new process for every new connection ? How is >>it being managed ? > > As long as you have a simple transaction system, one incoming request, > one outgoing response, why on earth would any sensible person create a > TCP/IP connection for this simple transaction ? To continue in the same confrontational tone: Because UDP doesn't work in practice except in some very limited scenarios. This is also why almost no widely used application protocols use UDP. If you're arguing that UDP is generally a better transport protocol than TCP, you're in a small minority. I also note that it was you who brought up these simple transaction systems. It's not implied in the text you quoted (although it does make pointless comparisons between the internal workings of UDP and TCP servers -- pointless because that's not what makes you decide to use TCP or UDP.) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
From: karthikbalaguru on 20 Feb 2010 16:26 On Feb 20, 11:13 pm, Joe Pfeiffer <pfeif...(a)cs.nmsu.edu> wrote: > karthikbalaguru <karthikbalagur...(a)gmail.com> writes: > > On Feb 20, 8:08 pm, markhob...(a)hotpop.donottypethisbit.com (Mark > > Hobley) wrote: > >> karthikbalaguru <karthikbalagur...(a)gmail.com> wrote: > >> > 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 . > > >> TCP is a "reliable" connection, whereas UDP is "unreliable". If you understand > >> the difference between these two types of connections, it should be clear why > >> this is so, and you would know which connection type best suits your > >> application. > > > Agreed, but the query is about the design of the > > TCP server and the UDP server. In TCP server > > whenever a new connection arrives, it accepts the > > connection and invokes a new process to handle > > the new connection request. The main point here > > is that 'a new process is created to handle every > > new connection that arrives at the server' . > > In the case of UDP server, it seems that most > > of the the server design is such that there is only > > one process to handle various clients. > > Will the TCP server get overloaded if it creates > > a new process for every new connection ? How is > > it being managed ? > > Tim Watts did an excellent job two posts up-thread describing three > different architectures for TCP servers. To summarize the part that > relates directly to your question: if you've got a really heavy load, > the server can indeed get overloaded. In that case, you need to work > harder and do something like a threaded or multiplexing server. > > True ! Need to decide on the best design methodology between either threaded or multiplexing server. > > >> > How is TCP server able to handle large number of very rapid > >> > near-simultaneous connections ? > > >> The datagrams carry identification numbers that enable them to be related > >> to the controlling processes, enabling them to be easily managed. > > > The point here is, consider a scenario that there are > > multiple connection requests are arriving while the > > TCP server is busy in the process of creation of a > > new process for the earlier connection request. > > How does TCP handle those multiple connection > > requests during that scenario ? > > That's what the backlog parameter on the listen() call is for. If the > number of pending requests is less than or equal to that number, they > get queued. When the number of pending requests exceeds it, requests > start getting refused. Great ! I checked thee backlog parameter, yes it seems to be providing support interms of queing :-) !! The below link seems to have some good info about backlog parameter - http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/023/2333/2333s2.html It seems that it plays a role in determining the maximum rate at which a server can accept new TCP connections on a socket. Interesting to know that the rate at which new connections can be accepted is equal to the listen backlog divided by the round-trip time of the path between client and server. Thx, Karthik Balaguru
From: Joe Pfeiffer on 20 Feb 2010 19:13 Paul Keinanen <keinanen(a)sci.fi> writes: > On Sat, 20 Feb 2010 08:15:13 -0800 (PST), karthikbalaguru > <karthikbalaguru79(a)gmail.com> wrote: > >> >>Agreed, but the query is about the design of the >>TCP server and the UDP server. In TCP server >>whenever a new connection arrives, it accepts the >>connection and invokes a new process to handle >>the new connection request. The main point here >>is that 'a new process is created to handle every >>new connection that arrives at the server' . >>In the case of UDP server, it seems that most >>of the the server design is such that there is only >>one process to handle various clients. >>Will the TCP server get overloaded if it creates >>a new process for every new connection ? How is >>it being managed ? > > As long as you have a simple transaction system, one incoming request, > one outgoing response, why on earth would any sensible person create a > TCP/IP connection for this simple transaction ? To avoid having to deal with dropped/corrupted packets yourself. -- As we enjoy great advantages from the inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. (Benjamin Franklin)
From: karthikbalaguru on 20 Feb 2010 22:05 On Feb 21, 4:19 am, Tim Watts <t...(a)dionic.net> wrote: > karthikbalaguru <karthikbalagur...(a)gmail.com> > wibbled on Saturday 20 February 2010 19:49 > > > > > Interesting to know a method for having a Light load TCP server > > by using the existing utilities in Linux/Unix in the form of > > Forking Server ! > > Yes, it's actually very simple. Get yourself a linux machine, write a > trivial program in perl,python, C, whatever that accepts lines on STDIN and > replies with some trivial (eg echo the contents of STDIN) back to STDOUT. > Run it and see if it does what you expect. > > Now configure xinetd (the modern inetd, usually the default on any modern > linux) to bind your program to say, TCP port 9000. > > On the same machine, telnet localhost 9000 and you should have the same > experience as running the program directly. telnet to it 3 times > simultaneously from 3 different terminal windows. telnet to it from a > different machine on your network. > > Interesting telnet example for TCP ! I checked link http://en.wikipedia.org/wiki/Inetd & it seems to have some good info about this just as you conveyed . I liked the errorlog feature via udp where only one instance of the service is running to service all requests. Interesting to know that by just specifying 'wait', the inetd can be configured to only use one instance of the server to handle all requests. > > >> 2 - Popular - little harder to program, much more efficient, assuming > >> your OS can handle thread creation more lightly than process creation. > > > Threaded Server seems to be good, but it might be > > overloading the TCP server very quickly incase of fast > > multiple connection requests within a very short timeframe. > > Just as you said, i think if the thread creation is of less > > overhead in the particular OS in which TCP server is > > running, then it would be great. > > Yes - if you don't mind thread programming - it does have its own peculiar > issues. > > > I came across preforking tricks too where a server launches > > a number of child processes when it starts . > > Apache does that in one of its modes (and it has several modes). That is an > example of a high performance bit of server software. Much more complicated > to manage of course and less likely to be suitable for a tiny embedded > system - but could be suitable for a decent 32 bit system with some sort of > OS. > > Interesting to know that Apache uses preforking tricks in which the server launches a number of child processes when it starts. > > > > > Those inturn > > would be serving the new connection requests by having > > some kind of locking mechanism around the call to accept > > so that at any point of time, only one child can use it and > > the others will be blocked until the lock is released. > > There seem to be some way out of that locking problem. > > But, i think the idea of creation of one child for every > > new connection/client seems to be better than the preforking > > trick, but these tricks in turn overload the TCP server > > incase of fast successive/near-simultaneous connection > > requests within a short time frame. > > Just as you said, i think if the thread creation is of less > > overhead in the particular OS in which TCP server is > > running, then it would be great. > > >> 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. > > > Having one process for maintaining states of all > > connections and implementing the event > > methodology that calls service subroutines whenever > > a certain specific instance happens sounds interesting. > > Appears to be the ultimate method for embedded systems > > where OS is absent and C is the main language . > > Anyhow, need to analyze the drawbacks if any. > > I actually used this when I coded a bunch of servers in perl [1] to > interface to dozens of identical embedded devices. It was actually mentally > much easier than worry about locking issues as all the separate connections > had to be coordinated onto one data set in RAM, ie they weren't functionally > independant. > But, was it robust enough to handle near-simultaneous multiple connections within a short timeframe from various clients ? Were you using some kind of buffering/pool mechanism which the main process was checking as soon as it is done with the action for a particular connection ? > [1] Yes perl. This was a rapid prototyping excercise to prove a point. My > aim was to recode in C if necessary. It wasn't as the overhead of using perl > was nearly two orders of magnitude less significant than the load of talking > to an RDBMS - so it stayed in perl working quite happily in production. > > >> 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? > > >> -- > Thx in advans, Karthik Balaguru
From: karthikbalaguru on 21 Feb 2010 03:33
On Feb 21, 4:34 am, Tim Watts <t...(a)dionic.net> wrote: > karthikbalaguru <karthikbalagur...(a)gmail.com> > wibbled on Saturday 20 February 2010 21:26 > > > > > True ! Need to decide on the best design methodology between > > either threaded or multiplexing server. > > I might have missed it - but what system is your code going to run on? > Linux, something else fairly "fat" or a teeny embedded system with no > resources? > Linux ! > It makes a difference, because there's no point in looking at (say) forking > servers if you have no processes! > :-) True ! > There is also the element of code simplicity and maintainability. If this > were running on a high end system, you might be better to use a well known > and debugged framework to manage your connections, so you write as little > code as possible and what you do write deals mostly with the actual logic of > your program rather than a whole overhead of connection management. No > disrepect intended on your programming abilities ;-> but less code is always > better :) > > I was in several minds how to approach my problem, until I found perl's less > well known IO::MultiPlex library - after that it was plain sailing with a > multiplexed server. If that hadn't existed, I might well have used a > multiprocess model with a lump of shared memory and some semaphores (I had > the advantage that there one only one persistent TCP connection incoming > from each of a finite number of embedded systems, so connection setup > overhead was lost in the wash) > -- Great. But, Is there a C language version of the same that can help in plain sailing with a multliplexed server ? I searched the internet to find the features available with perl's IO::Multiplex . It seems that IO::Multiplex is designed to take the effort out of managing multiple file handles. It is essentially a really fancy front end to the select system call. In addition to maintaining the select loop, it buffers all input and output to/from the file handles. It can also accept incoming connections on one or more listen sockets. It is object oriented in design, and will notify you of significant events by calling methods on an object that you supply. If you are not using objects, you can simply supply __PACKAGE__ instead of an object reference. You may have one callback object registered for each file handle, or one global one. Possibly both -- the per-file handle callback object will be used instead of the global one. Each file handle may also have a timer associated with it. A callback function is called when the timer expires. Any equivalent C language package available ? Thx in advans, Karthik Balaguru |