When using sockets for IPC, you can get the system to pick a random free port as described in this question here:
On localhost, how to pick a free port number?
There is a norm that you put the process ID in a ".pid" file so that you for example easy can find the apache process id and in this way kill it.
But what is the best practice way to exchange port number, when the OS picks a random port for you to listen on?
To inform about the port number you can use any other transport mechanism, which can be a file on the shared disk, pigeon mail, SMS, third-party server, dynamically updated DNS entry etc. The parties must have something common to share, then they can communicate. I omit port scanning here for the obvious reason.
There's one interesting aspect about not random ports but "floating" port number: if you don't want to keep the constant port but can choose the listening port within certain range, then you can use the algorithm for calculating actual port number based on date or day of week or other periodical or predictable information. This way the client knows where to look the server.
One more option is that during communication started on one port, the server and the client will agree where the server will wait for the client to have the next session.
Related
What is the difference between a "tcp/socket" and "tcp/ip" connexion?
When you say that you use "tcp/ip", do you necessarily use a "tcp/socket"?
Thanks!
A socket is a general communication means provided by your
operating system.
There are many kinds of them, for very distinct purposes
(not only networking).
I guess that when you think about tcp/socket, you mean a
socket dedicated to the TCP protocol.
TCP/IP can be seen as two different things, depending on the context.
It can be the TCP/IP network stack as a whole: not only the TCP and IP
specific protocols but the set of protocols (and implementations) we
find around these.
Of course, the other way to see TCP/IP is to consider only the TCP
transport protocol relying on the IP network protocol.
The various operating systems implement many protocols
in the TCP/IP stack.
To use them, a programmer asks his/her operating system
a specific resource: a socket.
It's difficult to say more with few words.
Some books or online documentation could help go further.
I think you missing something in the question. Anyway in short...
TCP/IP is basically name given to protocol we (networking devices) follow it forms the fundamental of todays internet. It involves agreement between two devices how the want ro communicate eg. Which segment of a frame has what information as in the end its all just 10...
There are 5 layers (some argue 4) in this model one layer is Network Layer right at the middle of all and it generally uses IPv4.And just above this is our Transport Layer which may use TCP or UDP as protocol depending on service you want. So thats the summary of TCP/ IP as the most used set of protocols of all.
When connecting to a remote server your browser needs to know what kind of service he is about to get from that server eg. a video mail or file transfer or just a http page. Thats when a TCP/Socket comes into picture where there is a port no assigned for every service. Eg port 443 is for https and so on. All you need to do is open a socket connection over that port number on that machine
Remember if a particular port of a server is not in LISTEN mode you cannot connect to that application via that port
Eg. If a server serves its webpage it might not allow you to connect its port responsible for FTP.
I understand why a server would need sockets for incoming data, but I do not understand why it is necessary that a socket connecting to another computer needs a source port.
While others have mentioned the exact reason why, let me illustrate the point by giving you an example:
Say you want to ssh to your server. OK, you ssh in and do some stuff. Then you tail a log file. So now you don't have access to the console anymore. No problem you think, I'll ssh again...
With one port number, if you ssh again that second connection will be a mirror of the first since the server won't know that there are two connections (no source port number to tell the difference) so you're out of luck.
With two port numbers you can ssh a second time to get a second console.
Say you browse a website, say Stackoverflow. You're reading a question but you think you've seen it before. You open a new tab in your browser to stackoverflow to do a search.
With only one port number the server have no way of knowing which packet belongs to which socket on the client so opening a second page will not be possible (or worse, both pages receive mixed data from each other).
With two port numbers the server will see two different connections from the client and send the correct data to the correct tab.
So you need two port numbers for client to tell what data is coming from what server and for the server to tell what data is coming from which socket from the client.
A TCP connection is defined in terms of the source and destination IP addresses and port numbers.
Otherwise for example you could never distinguish between two connections to the same server from the same client host.
Check out this link:
http://compnetworking.about.com/od/basiccomputerarchitecture/g/computer-ports.htm
Ultimately, they allow different applications and services to share the same networking resources. For example, your browser probably uses port 80, but your email application may use port 25.
TCP communication is two-way. A segment being sent from the server, even if it is in response to a segment from the client, is an incoming segment as seen from the client. If a client opens multiple connections to the same port on the server (such as when you load multiple StackOverflow pages at once), both the server and the client need to be able to tell the TCP segments from the different connections apart; this is done by looking at the combination of source port and destination port.
As we know in any web application for a tab in a browser there is one process so we require an ip address and a port number to identify the process. As we know for every tab there is unique port number. So for every process there is unique process id. Also instead of using ip and port number combination can we use ip and process id combination in socket programming. And if so then how? And if not why? Please can you help me.. Sorry for the bad English
Can we use IP address and process id combination instead of IP address and port number?
No.
Why and why not?
Because they didn't define TCP/IP that way. It doesn't make sense. A remote computer doesn't have a way of discovering a process ID on another host. What it needs is a fixed number, i.e. a port number, which both hosts can implement.
As we know for every tab there is unique port number.
This is absolutely and definitely incorrect. 'We' don't 'know' any such thing.
As we know in any web application for a tab in a browser there is one process
That is not guaranteed. That is an implementation detail of the browser. It may or may not use a separate process for each tab.
so we require an ip address and a port number to identify the process.
No, you need an IP address and port to identify a given socket endpoint. A process can have more than one socket active.
As we know for every tab there is unique port number.
That is not guaranteed, either. HTTP is stateless, and connections are not guaranteed or required to stay connected between requests, especially for long periods of time. Say you open a tab and request a given website, leave the tab open for awhile, and then open a new tab to a different website. The previous connection(s) may have been closed while the tab sat idle, and those port(s) may be available for re-use in the new tab.
So for every process there is unique process id.
That is the only thing that is guaranteed in this situation. But remember that once a process ends, its process id can and will be re-used in a subsequent new process.
Also instead of using ip and port number combination can we use ip and process id combination in socket programming.
No. But on some platforms, such as Windows, there are APIs available to discover the process ID that owns a given socket, at least.
if not why?
Because that is not how sockets are designed to operate. A socket endpoint is identified by its protocol/IP/port tuple, and a socket connection is identified by the protocol/IP/port tuple of the two peers that are connected to each other. Remember that a socket connection can span across machine boundaries, but a process ID is only local to the machine it is running on.
I am testing a simple client/server application. My unit tests on client side need the server up, but I seem to be getting hangs (individual tests work, but not more than one).
As part of my tearDown(), I thought it would be good to close the server socket, but... since I have no way of getting access to the server object, from the client code, I can't do a simple: serverSocket.close(). That said, I do know what port number the socket is running on, with the port number alone, is it possible to close a socket, irrespective of where/how the object using it resides?
Sorry for what is probably a trivial question... thanks...
I suppose another related question is... can I create a socket based on a port number already in use?
No. You need to get the server software to close the port.
The only other alternative is killing the server: you can identify the process that has the port open with lsof or netstat, then kill the process. That's a brutal way to free a port though. In your case, you'd be much better off fixing your software not to hang!
If the socket is in your process, what you can do is iterate over all file descriptors from 0 to getrlimit(RLIMIT_NOFILE) and invoke getsockname() on each of them. If the call succeeds and the port number matches you have found your socket by port number (beware though, the may be multiple sockets with the same port number but bound to different addresses).
I apologize for the weird question wording... here's the design problem:
I am developing a server (on Linux using C++, FWIW) that provides a service to many instances of a client application running on consumer PCs.
I want the following:
1) All clients first identify themselves to a "gatekeeper" server application. Consider this a login procedure, with credentials like a user name and password being passed in. Call the gatekeeper program "gserver". (for gatekeeper.)
2) Once each client has been validated, it is then placed into a long term connection with one of several instances of a different server application running on the same physical server box bound to the same server address. Call any of these instances "wserver" (for "working" server.)
So, what the client sees is that a "gatekeeper" application gives it passworded access to one of several "working" servers running on the same box.
Here is the "real" challenge: we want to exclusively use a "well known" port number for the inbound server connections (like port 80 or 443, say.) Or, our own "well known" port.
We would prefer not to have to make the client talk to a second port on the server for the long term connection phase with wserver(n). The problem with this, of course, is that only one server process at a time can be bound to the same port and server address.
This implies that a connection made by the client with gserver must also fill the role of the long term connection. The only way I see to accomplish this is that gserver must, after login, act like a proxy and copy traffic between itself and the client to the particular wserver(n) that the client is bound to logically.
It would be ideal if a TCP/IP connection first made between client(n) and gserver could be somehow "transported" to another application on the same server, intact, and could then be sustained by one of the wserver(n) instances for the long term connection.
I know that web servers do something like this for spreading out server loads. "Load balancing". The main difference here is that the "balancing" is the allocation of a particular user to a particular wserver(n) instance. But I also have the impression that load balancing is a kind of proxying - which I am trying to avoid (since it complicates the architecture and adds overhead as well as a single point of failure.)
This is a conceptual and design question. Don't worry about source code examples, unless they are absolutely essential to get the ideas across. If we pin down an approach, I can code it up.
Thanks!
What you are looking for is file descriptor passing. See UNP 15.7. One well-known heavy user of this facility is postfix.
I developed such an application long time ago. Since multiple servers can't listen on the same port. What you need is to have gserver listening on the well-known port. Once connection is established, pass the connection to the other servers via an Unix socket. Once the connection is passed to other server, gserver is out of picture. It can die and the other server will be still serving the connection.
I dont' know if this applies to your design, but the usual solution (as implemmented by the xinetd daemon) is to fork() and then exec() the process. For example, xinetd may serve services like rlogin, rsh, tftp, telnet, etc. which are actually served by different programs. This will not be useful to you if your wservers are processes already running in the system.