In socket programming, you create a listening socket and then for each client that connects, you get a normal stream socket that you can use to handle the client's request. The OS manages the queue of incoming connections behind the scenes.
Two processes cannot bind to the same port at the same time - by default, anyway.
I'm wondering if there's a way (on any well-known OS, especially Windows) to launch multiple instances of a process, such that they all bind to the socket, and so they effectively share the queue. Each process instance could then be single threaded; it would just block when accepting a new connection. When a client connected, one of the idle process instances would accept that client.
This would allow each process to have a very simple, single-threaded implementation, sharing nothing unless through explicit shared memory, and the user would be able to adjust the processing bandwidth by starting more instances.
Does such a feature exist?
Edit: For those asking "Why not use threads?" Obviously threads are an option. But with multiple threads in a single process, all objects are shareable and great care has to be taken to ensure that objects are either not shared, or are only visible to one thread at a time, or are absolutely immutable, and most popular languages and runtimes lack built-in support for managing this complexity.
By starting a handful of identical worker processes, you would get a concurrent system in which the default is no sharing, making it much easier to build a correct and scalable implementation.
For TCP, no. You can only have one application listening on the same port at one time. Now if you had 2 network cards, you could have one application listen on the first IP and the second one on the second IP using the same port number.
A socket that has been established as a server can accept connection requests from multiple clients.
@FernandoGonzalezSanchez: A single client can have multiple TCP sockets bound to the same local IP/Port pair as long as they are connected to different remote IP/Port pairs.
That's right, sockets are a way for two processes to communicate regardless of whether it's over the network or within the same machine. You could invent other mechanisms for communication within the same machine (and there are plenty), but why if sockets already serve that purpose perfectly fine? >Fine deceze.
You can share a socket between two (or more) processes in Linux and even Windows.
Under Linux (Or POSIX type OS), using fork()
will cause the forked child to have copies of all the parent's file descriptors. Any that it does not close will continue to be shared, and (for example with a TCP listening socket) can be used to accept()
new sockets for clients. This is how many servers, including Apache in most cases, work.
On Windows the same thing is basically true, except there is no fork()
system call so the parent process will need to use CreateProcess
or something to create a child process (which can of course use the same executable) and needs to pass it an inheritable handle.
Making a listening socket an inheritable handle is not a completely trivial activity but not too tricky either. DuplicateHandle()
needs to be used to create a duplicate handle (still in the parent process however), which will have the inheritable flag set on it. Then you can give that handle in the STARTUPINFO
structure to the child process in CreateProcess as a STDIN
, OUT
or ERR
handle (assuming you didn't want to use it for anything else).
EDIT:
Reading the MDSN library , it appears that WSADuplicateSocket
is a more robust or correct mechanism of doing this; it is still nontrivial because the parent/child processes need to work out which handle needs to be duplicated by some IPC mechanism (although this could be as simple as a file in the filesystem)
CLARIFICATION:
In answer to the OP's original question, no, multiple processes cannot bind()
; just the original parent process would call bind()
, listen()
etc, the child processes would just process requests by accept()
, send()
, recv()
etc.
Most others have provided the technical reasons why this works. Here's some python code you can run to demonstrate this for yourself:
import socket import os def main(): serversocket = socket.socket(socket.AF_INET, socket.SOCK_STREAM) serversocket.bind(("127.0.0.1", 8888)) serversocket.listen(0) # Child Process if os.fork() == 0: accept_conn("child", serversocket) accept_conn("parent", serversocket) def accept_conn(message, s): while True: c, addr = s.accept() print 'Got connection from in %s' % message c.send('Thank you for your connecting to %s\n' % message) c.close() if __name__ == "__main__": main()
Note that there are indeed two process id's listening:
$ lsof -i :8888 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME Python 26972 avaitla 3u IPv4 0xc26aa26de5a8fc6f 0t0 TCP localhost:ddi-tcp-1 (LISTEN) Python 26973 avaitla 3u IPv4 0xc26aa26de5a8fc6f 0t0 TCP localhost:ddi-tcp-1 (LISTEN)
Here are the results from running telnet and the program:
$ telnet 127.0.0.1 8888 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Thank you for your connecting to parent Connection closed by foreign host. $ telnet 127.0.0.1 8888 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Thank you for your connecting to child Connection closed by foreign host. $ telnet 127.0.0.1 8888 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Thank you for your connecting to parent Connection closed by foreign host. $ python prefork.py Got connection from in parent Got connection from in child Got connection from in parent
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With