I have a Server-Client program using java, I tried to create a ServerSocket with a port and Client Socket with different port and they cannot connect to each other. Client throw ConnectException. When I change the socket on Client to the same as the one I use for ServerSocket, they worked.
As I understand from the aswer from this thread Java Networking: Explain InputStream and OutputStream in Socket if a machine create a socket with a port then that socket is bind to that machine, so why do client and server need to use same port to connect to each other?
Also, two application can't use same port on a machine so what happen when two difference Server having same port and a machine need to connect to both of them through 2 different application?
You need some basic understanding of TCP communication. Just Google TCP tutorials.
In a nutshell; the server will listen on a specific port. When a server is listening on a port it is bound to it. Only one server (or process) on a machine can be listening on a certain port.
The client will connect to a machine and specify the port to communicate on. If the server is listening on the port the client asked, then comms happens. Otherwise the connection cannot continue.
So the port that the server is bound to (or listening on) must be the same as the port the client specified.
The client and server don't need to use the same port. As you pointed out, a port can only be allocated to a single process at a time on a machine. To be more correct, a port and IP address pair is the allocation unit. So if your machine has two addresses or more one can bind the port to different processes per IP.
The standard setup is for the server process to listen for connections on a port, say 10000 using a server socket. The client process tries to connect to that port using a client socket. It will use a OS allocated port. Once the connection is setup, the server will allocate another client socket, on its side, in order to manage communication with the client process, and this will also have a OS allocated port.
Answer is NO, server will listen on a specific port but when the client start connecting to server
For example: Server is listening on port 80
When client connect to server, it will connect to serverIP address on port 80.
Client socket is live on another port, it is allocated by OS
Related
I use
InetAddress addr = InetAddress.getByName("127.0.0.1");
in order to specify my host name and then I use the same number in my client code.
However, when I run client code on a different computer which is not on the same host, it does not connect to the server socket.
How can I write the client code, so that every computer can access and connect to the server code?
I think this will work.
InetAddress addr = InetAddress.getByName("0.0.0.0");
This will bind your socket to all available network interfaces.
You can use 127.0.0.1 from your host and your LAN ip from local network.
However, when I run client code on a different computer which is not
on the same host, it does not connect to the server socket.
Since you're looking for a socket on 127.0.0.1, which is the loopback interface, it is because the server is not running on the other computer. Run the server on the other computer and it should work.
How can I write the client code, so that every computer can access and
connect to the server code?
The client must be aware of IP and port of the server. IP+port make up the server socket. For the connection to work in a network the server should accept connections on a network address, not just localhost. If the client connects to the server from host A, then it will connect from any host B, if B knows how to reach the server and there's nothing blocking the connection between B and the sever.Read more about sockets in Java here.
I've seen many answers similar to this one in regards to serversockets in java: "Let's say you have a server with a serversocket on port 5000. Client A and Client B will be connecting to our server.
Client A sends out a request to the Server on port 5000. The port on Client A's side is chosen by the Operating System. Usually, the OS picks the next port that is available. The starting point for this search is the previously-used port number + 1 (so for instance if the OS happened to us port 45546 recently, the OS would then try 45547).
Assuming there are no connection problems, the Server receives Client A's request to connect on port 5000. The Server then opens up its own next available port, and sends that to the client. Here, Client A connects to the new port, and the server now has port 5000 available again."
I've seen answers like this in multiple questions on stackoverflow about how a different port is used in the returned socket of the accept() than the port that the ServerSocket is listening on. I was always under the impression that TCP is identified by the quartet of information:
Client IP : Client Port and Server IP : Server Port ->protocol too (to distinguish TCP from UDP)
So why would the accept() need to return a socket bound to a different port? Doesn't the quartet of information sent in every header distinguish multiple connections to the same server port from different machines enough where it would not need to use different ports on the server machine for communication?
The Server then opens up its own next available port, and sends that to the client.
No. It creates a new socket with the same local port number. No second port number is allocated or sent to the client. The SYN/ACK segment which is the server's response to the connect request does not contain a second port number.
Here, Client A connects to the new port,
No. The client acknowledges the SYN/ACK packet and the client is connected to the original port from then on, after acknowledging the SYN/ACK. There is no second connect.
and the server now has port 5000 available again."
It always did.
I've seen answers like this in multiple questions on stackoverflow about how a different port is used in the returned socket of the accept() than the port that the ServerSocket is listening on.
Any such answer is incorrect and should be downvoted 'with extreme prejudice' and commented on adversely. The TCP handshake is defined in RFC 793 and does not specify allocation and exchange of a second port and a second connect message. There are only three messages, which isn't even enough for that to occur.
So why would the accept() need to return a socket bound to a different port?
It doesn't.
Doesn't the quartet of information sent in every header distinguish multiple connections to the same server port from different machines enough where it would not need to use different ports on the server machine for communication?
Yes.
You are correct in the TCP packet header's information. It contains:
Client IP | Client Port | Server IP | Server Port | Protocol
Or, more appropriately (since client/server become confusing when you think about bi-directional transfer):
Source IP | Source Port | Destination IP | Destination Port | Protocol
Multiple connections to the same server port will come from different ports on the client. An example may be:
0.0.0.0:45000 -> 1.1.1.1:80
0.0.0.0:45001 -> 1.1.1.1:80
The difference in client ports is enough to disambiguate the two sockets, and thus have two separate connections. There is no need for the server to open another socket on another port. It does receive a socket from the accept method, but it's assigned to the same port and is now a route back to the newly accepted client.
FTP, on the other hand, does have a model where the server will open a new unprivileged port (> 1023) and send that back to the client for the client to connect to (this is referred to as "Passive FTP"). This is to resolve issues where the client is behind a firewall and can't accept incoming data connections from the server. However, this is not the case in a typical HTTP server (or any other standard socket implementation). It's functionality that is layered on top of FTP.
I know one socket connection are established by both Server Socket and Client Socket.
And I read some documents said one Server Socket could serve many Client Sockets, means one Server Port could server multi Client Ports.
1.But I wonder that does Server use random ports to server different Clients after connection under hood, or Server just uses the same port listening and serving many client's connections ?
2.If so, when I implement a Server and Client Socket Connection, could I random a new port to establish a new Server Socket and tell Client to reconnect to new Server Socket, and the listening Server Socket just keep listening other clients ? it means use different port to server different clients ?
3.And what is the advantage of using one Server Socket(port) to server many Client? and advantage of using multi Server Sockets(ports) to server different Clients?
Thank you
The two value that idenify each end point, ip address and port number often called socket.
A server socket listens on a single port. All established client connections on that server are associated with that same listening port on the server side of the connection.Multiple connections on the same server can share the same server-side IP/Port pair as long as they are associated with different client-side IP/Port pairs, and the server would be able to handle as many clients as available system resources allow it to.
var express = require('express');
var app = express();
var server = require('http').createServer(app);
var io = require('socket.io')(server);
server.listen(4200);
Here u can attach your http port with socket.io.
by using a random client-side port, in which case it is possible to run out of available ports if you make a lot of connections in a short amount of time.
for more detail visit this site
In the server side, i use this code :
ServerSocket server = new ServerSocket(1234);
Socket server_socket = server.accept();
I found the server is listening on port 1234.
When one or more client sockets are connected, they are all using the same port 1234 !
That is really confusing :
I remember that multi sockets can't use the same port, isn't it right ? Thanks.
A TCP connection is identified by four numbers:
client (or peer 1) IP
server (or peer 2) IP
client port
server port
A typical TCP connection is open as follows:
The client IP is given by the client's ISP or NAT.
The server IP is given by the user or looked up in a DNS.
The client chooses a port arbitrarily from the unassigned range (while avoiding duplicate quadruples)
The server port is given by the protocol or explicitly.
The port that you specify in the ServerSocket is the one the clients connect to. It's nothing more than a port number that the OS knows that belongs to your application and an object that passes the events from the OS to your application.
The ServerSocket#accept method returns a Socket. A Socket is an object that wraps a single TCP connection. That is, the client IP, the server IP, the client TCP port and the server TCP port (and some methods to pass the associated data around)
The first TCP packet that the client sends must contain the server port that your app listens on, otherwise the operating system wouldn't know what application the connection belongs to.
Further on, there is no incentive to switch the server TCP port to another number. It doesn't help the server machine OR the client machine, it needs some overhead to perform (you need to send the new and the old TCP port together), and there's additional overhead, since the server OS can no longer identify the application by a single port - it needs to associate the application with all server ports it uses (the clients still needs to do it, but a typical client has less connections than a typical server)
What you see is
two inbound connections, belonging to the server (local port:1234). Each has its own Socket in the server application.
two outbound connections, belonging to the client (remote port:1234). Each has its own Socket in the client application.
one listening connection, belonging to the server. This corresponds to the single ServerSocket that accepts connections.
Since they are loopback connections, you can see both endpoints mixed together on a single machine. You can also see two distinct client ports (52506 and 52511), both on the local side and on the remote side.
I've a server (Java) and a number of clients (c++), connected by sockets.
I would like to set the ports automatically.
Assuming the IP is already known.
In the Java side I can make :
ServerSocket s = new ServerSocket(0);
So now I've a random free port on the server.
How can I know in the C++ side, what port is the server listening to?
I think is not possible, if you want establish a connection with a server, you must know in which port is the server listening, there are programs like nmap that shows you a list of opened ports in a server, but a server can have many opened ports at the same time and then, How do you know what is the port opened by your server? and in any case, is too slow and inefficient to call external tool, read and parse its output. For what reason do you need a random port service?
Other option can be get the opened socket in the server side calling to s.getLocalPort() and send it via UDP for any listening node in the network with broadcasting, and re-program the client side to listen in broadcast and when it receives a message, check if it is a port number and connect to the server using that port.
You can't, not reliably. In IP, a machine is identified by an address. A server (ie, a service) is identified by an address and a port. You clients need some form of "known service" that they can connect to.
If you, for whatever reason, absolutely want to have dynamic listening port, you could combine it with a "locator" service on a known port. For instance, have a web service/servlet on the standard http port (80). Your clients connect to the "locator" service (always on port 80) and asks which port your application is currently listening on. This is a not entirely uncommon pattern. RMI works is a similar way where you have a registry on a known port. Clients connect to the registry and asks for the location of RMI endpoints.