Interesting telnet example for TCP ! I checked link
formatting link
& 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.
r
an
ed
of
Interesting to know that Apache uses preforking tricks in which the server launches a number of child processes when it starts.
ng
f
a
of
ap
ly
ns
lly
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 ?
karthikbalaguru wibbled on Sunday 21 February 2010 03:05
Yes to the first question. The OS takes care of that. Within (quite large) limits, linux (and any other "proper" OS will buffer the incoming SYN packets until the application gets around to doing an accept() on the listening socket. The application doesn't have to worry about that as long as it isn't going to block on something else for some silly amount of time.
In practice, it was 10's of milliseconds at most.
Different issue of course on a tiny system (you still haven't said what your target system is).
--
Tim Watts
Managers, politicians and environmentalists: Nature's carbon buffer.
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.
Okay , it is not a problem until the buffer is able to buffer the packets without overflowing. I have been searching the internet regarding the buffering and arrived at various links for linux -
formatting link
formatting link
formatting link
- 'sysctl' seems to hold key !
- I do find /proc special file can also be accessed for configuring the system parameters .
Set maximum size of TCP transmit window - echo 108544 > /proc/sys/net/core/wmem_max Set maximum size of TCP receive window - echo 108544 > /proc/sys/net/core/rmem_max Set min, default, max receive window. Used by the autotuning function
- echo "4096 87380 4194304" > /proc/sys/net/ipv4/tcp_rmem Set min, default, max transmit window. Used by the autotuning function
This is like a singly-linked list. It's the first thing you learn, and so many people tend to assume it's used a lot in the real world. In actuality, it's only common in special cases, such as when each instance needs its own security context (like in 'telnetd' and 'sshd').
This is the norm for TCP too, most of the time. But it's more obviously reasonable for UDP, since there are no connections. You can't create one process for each connection because there's no such thing.
To the extent there is such a difference, it's because of the different things the servers do. For example, TCP is commonly used for web servers. Each web connection is a separate logical operation with multiple steps that affect only that operation. However, a typical UDP server (such as a time server or resolver) needs to maintain some global state that each packet received minorly interacts with.
Process-per-connection servers tend to do this very poorly. But one trick is to create the processes before you need them rather than after.
But it is _*FAR*_ higher than _*ANY*_ other protocol.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
The trick of creating the process before the actual need sounds interesting and appears similar to pre-forking. Here a 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.
Note that this is a key weakness of the 'process-per-connection' model, and I recommend just not using that model unless it's mandated by other concerned (such as cases where security is more important than performance).
But there are two techniques, and they are typically used in combination. One is static configuration. This is key on initial server startup. For example, versions of Apache that were process per connection let you set the number of processes to be started up initially. They also let you set the target number of 'spare' servers waiting for connections.
The other technique is dynamic tuning. You monitor the maximum number of servers you've ever needed at once, and you keep close to that many around unless you've had long period of inactivity.
Servers are going to be slow to start up anyway, and the time to create new processes is not way out of line with the time to fault in pages of code and other delays during server startup that you can do very little about.
karthikbalaguru wibbled on Sunday 21 February 2010 08:57
Most of those are are "per connection" limits, not "per system".
formatting link
They help make things faster under certain conditions, but are not related to the kernel max resources.
You generally need not worry about kernel resources - they are comparatively enormous.
On my system:
/proc/sys/net/ipv4/tcp_max_syn_backlog is set to 1024 - that is a per system limit, but it can be increased without issues (simply at the expense of something else).
Like having 1+GB (or TB if you use serious iron) on one system and 4k on the other! In the former, you generally don't care about trivial like network buffers - there is so much RAM the kernel will sort itself out.
On 4k, you have space for a couple of 1500 byte ethernet packets and some RAM for your application. OK - SYN packets aren't 1500 bytes and they can be processed into a very small data structure - but you get the point. Not much space and every byte matters.
--
Tim Watts
Managers, politicians and environmentalists: Nature's carbon buffer.
karthikbalaguru wibbled on Sunday 21 February 2010 08:33
OK - Stop worrying until it becomes a problem then tune the kernel. Make reasonable efforts to make the server app efficient but don't kill yourself unless you are writing something so outlandishly loaded that special considerations are needed. BTW - this is quite a rare requirement in practice.
Honestly don't know. C++ might have something?
But you have the freedom now to implement any of the strategies. How about a worker pool of processes with a master doing the listen() and handing off each new connection to an idle worker child? This would be good if the connections have little interaction with each other. If the interaction is heavy, you could either:
a) Use processes with IPC; b) Use threads; c) Do multiplexed;
or (sometimes overlooked - depends on the releative weight of the server's non mutually interactive code with the interactive bit)
d) Make the server processes totally non interactive and move the interactive logic to another server process which communicates with the first server over unix domain sockets (these are quite efficient in linux).
Just another idea.
You'll have to wait for someone else or google a bit more.
If you can read perl (even if you don't really use it) you could rip off IO::Multiplex and make a C or C++ library that implements exactly the same API. It's fairly easy to do a line by line translation of perl to C or C++. If you're feeling nice you could even opensource your library.
License issues may exist if you do a direct line by line rip off without opensourcing it - I'm not a lawyer, just be aware.
But either way, you should be on reasonably safe ground taking inspiration from it.
Multiplexing servers work well for servers that process connection data fast and deterministically without blocking for long (or not at all). If your process may block talking to a database (for example) then you will face the problem of blocking the whole server if you're not careful. In which case there is much to be said for forking or threaded servers as at least the kernel will help you out.
Cheers
Tim
--
Tim Watts
Managers, politicians and environmentalists: Nature's carbon buffer.
If it is really just the creation time that is an issue for running many processes, one could always be waiting as a hot spare. When it is then turned loose for a new connection a new process could then be created as a background task.
But, how is that technique of 'process-per-connection' very helpful for security ?
In case of static configurations, wouldn't that target number of servers started initially load the server ? There seems to be a drawback in this approach as the 'spare' servers/processes might be created unnecessarily even if there are only less clients. That is, if there are less clients, then those servers will be waiting for connections unnecessarily. This in turn would consume system resources.
Dynamic tuning appears to overcome the drawbacks w.r.t static configuration, But the scenario of 'long period of inactivity' requires some thought. During that time, we might need to unnecessarily terminate and restart enough number of processes. But, since we cannot not be completely sure of the time of maximum traffic arrival, we might land up in having all those servers running unnecessarily for long time :-( . Any thoughts ?
The process of termination and recreation also consume system resources.
karthikbalaguru wibbled on Monday 22 February 2010 04:19
You need to tell us more about your system (hardware spec, purpose of server, expected load).
Most of the time no one would care about the trivial space consumption of one forked process, even on low end hardware (remember, it is a *forked* process - the code pages are shared with every other forked sister (assuming no exec() has taken place) and even the data space is initially shared COW:
formatting link
So the only resource wastage is a PCB (process control block) including a set of page tables[1]
[1] Check these - have a feeling with some hardware, it *may* be possible that these start out shared COW too - no 100% sure...
--
Tim Watts
Managers, politicians and environmentalists: Nature's carbon buffer.
David Schwartz wibbled on Monday 22 February 2010 05:57
Specifically for the OP, threads can stamp all over the memory of sister threads. Processes can not do this, unless they are running with privilege (eg root or the correct capability bit set) - even then it would be a PITA.
Never trust the input data - ever. You may think the threads cant touch each other, but lack of checking on bad input data (from the socket) causing thread confusion and buffer smashing is the classic hack.
Process isolation is another layer of protection, though it is no excuse for not sanitising the data too :)
--
Tim Watts
Managers, politicians and environmentalists: Nature's carbon buffer.
In general, he needs to tell us what his goal with this discussion is. The questions jump all over the place, and every answer immediately spawns N new questions -- with no clue what (if anything) he's trying to accomplish, other than perhaps a focus on extremely high accept() load.
Perhaps the OP would be better served by a book. You cannot learn all you need to know about socket programming from a Usenet thread. I recommend Stevens' "Advanced Programming in the Unix environment" vol
1, and "TCP/IP Illustrated vol 1" in order to make sense of the former.
Incase of heavy flow of data/messages, i think a queue mechanism will be required so that the master puts in the queue and the worker child reads from it whenever data is available in the queue. It looks like the queue mechanism cannot be ruled out incase of heavy interactions.
e
+.
n
ast
the
Multiplexing servers appear very interesting. Any link that talks in detail about this ?
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.