Ive got a c++ program that acts as a server (sends/receives). I'm trying to connect to the port that the server is using (say 2222). However, the message I'm getting is that the port is already bound to. The port is in use. I'm wondering how can I connect to this open port (bearing in mind the c++ tcp program is closed source)? I can change the source of the c++ program if needed, but it seems strange that I cannot just connect to the port it's using. I wonder do I need to implement threading in the tcp program, so that the send and receive's are using a different port?
There are two ports involved in a TCP connection. The incoming port that the server is listening on and the outgoing port that the client is connecting on.
They don't need to be the same port.
If both client and server are running on the same machine, then they can't be the same port because that port is already in use (by the server, presumably).
If that's the case, bind the client socket to port 0 instead, which basically says "give me any available port".
Related
I want to write a tcp server and client application, which has several different connections to each other where the client uses the same port number.
So far I understand it, the server has a listener port and when the client calls it, then I get a new socket for this new connection on the server side, when I call
accept();
Right? So on Server side I can identify my connection with this new socket and send data through it.
Now my understanding problem with the client side. There I get my socket when I call
socket(AF_INET, SOCK_STREAM, 0)
so I have only one socket. In the
connect()
I can specify remote adress and so on. So when I understand it correctly I can use one socket to make several connects to different adresses/port pairs to create different connections. Right?
But how can I now see in the Client from which logical connection I receive my data or how can I send it when 2 logical connections use the same local port at the client? On serverside I have 2 sockets when I have 2 accept called but what about the client side? For send and receive I have only one socket handle?
Or do I have to call socket() for each logical connection on the client?
I can specify remote adress and so on. So when I understand it correctly I can use one socket to make several connects to different adresses/port pairs to create different connections. Right?
No. A socket is the combination of IP address plus port number.
Or do I have to call socket() for each logical connection on the client?
Yes.
It seems to me your confusion arises because you think for example that a certain port is used for SMTP connections and a certain port is used for HTTP connections.
Well, that port alone is NOT defining for you a socket to the server. The IP address of the server is changing.
As an example, consider the following scenario:
You want to connection to Stackoverflow:
Your PC – IP1+port 50500 ——– Stackoverflow IP2 + port 80 (standard http port)
That is the combination IP1+50500 = the socket on the client computer and IP2 + port 80 = destination socket on the Stackoverflow server.
Now you want to connect to gnu.org:
your PC – IP1+port 50501 ——–gnu.org IP3 +port 80 (standard http port)
The combination IP1+50501 = the socket on the client computer and IP3 + port 80 = destination socket on the gnu.org server.
Better check out Beej's Network Programming to learn more. It is a must-read for anyone working with sockets.
So when I understand it correctly I can use one socket to make several connects to different adresses/port pairs to create different connections. Right?
No. A TCP socket can only be used once. When its connection has finished, or even if connect() just fails to make a connection, you must close the socket and create a new one if you want to make a new connection.
But how can I now see in the Client from which logical connection I receive my data or how can I send it when 2 logical connections use the same local port at the client?
Every TCP connection will have its own unique socket allocated for it. It is your responsibility to keep track of them.
On serverside I have 2 sockets when I have 2 accept called but what about the client side?
The exact same thing happens on the client side, too. You need to create and connect a separate socket for every TCP connection you make. So, you will have a new pair of socket()/connect() calls for every connection.
For send and receive I have only one socket handle?
No, you will have a separate socket for each connection, just like on the server side.
Or do I have to call socket() for each logical connection on the client?
Yes, and connect(), too.
I will not talk about a specific programming language rather I will give a general answer that is applicable for all:
In networking what you care about is the socket (IP+Port) this should be unique whether it is server/client socket or UDP/TCP socket.
For server sockets you must assign a port. For client sockets usually you do not specifically assign a port but it will be assigned by the operating system automatically. However, you can still assign a port to a client socket manually (e.g. in case some port numbers are blocked by the firewall)
In the server process:
you can get the server socket info and the connected client socket info
In the client process:
you can get the client socket info and the server (you want to connect to) socket info (of course you should know the server socket info previously otherwise how will you connect to it).
You can send/receive from/to client sockets. After the server gets the connected client socket it can send/receive through it. Same for the client side it can send/receive through its socket.
The "socket" abstraction is an unfortunate relic of past network stack design. It mixes two different sorts of objects.
A listening socket on the server has a port, and potentially an IP address of the local interface. However, this can also be 0.0.0.0 when listening on all interfaces.
A connected socket is associated with a TCP connection, and therefore has 4 parameters: {local IP, local port, remote IP, remote port}.
Now on the client side, you typically don't care about local IP or local port, so these are locally assigned on connect. And yes, these local parameters can in fact be reused for multiple connections. Only the 4-tuple of {local IP, local port, remote IP, remote port} needs to be unique. The OS will map that unique tuple to your SOCKET.
But since you need a new 4-tuple for every connection, it also follows you need a new SOCKET on both sides, for every connection, on both client and server.
I have two computers, and I have created a network between them, One is server (Windows Server OS) and the client (Windows 10). Both computer also has connection to internet through wifi. To connect two Systems I am using Ethernet Cable
I like to know if I create a program for client in c++ that send packets using internet socket. Should I also create a listener on server too. And should I use port 80 to send packets and same port on server to listen to arriving packets?
Assuming you decide to use TCP, then:
Should I also create a listener on server too?
If you are using a connection-oriented protocol (such as TCP) then you must have one end listening, because otherwise you have no way to create the TCP connection.
And should I use port 80 to send packets and same port on server to listen to arriving packets?
You should use whatever port number you want, as long as something else isn't using it. The actual number doesn't matter as long as the server and client agree.
Valid port numbers are in the range 1 to 65535.
I'm working on a server, which is listening on the port 80
I would like to enable both native and websocket clients to connect to my server.
It works only, if websockify runs at a different port, and forwards the trafic to the socket server.
Unfortunately websockify isn't well documented, and there are no tutorials available.
Where should I start, if I would like to create a single server only, which is listening on only one port, and accepts both websocket and native TCP sockets?
If your server is listening for connections on port 80, is it talking http? Because if not, don't be listening on port 80: Port 80 is well established as carrying http traffic.
Next - an ipaddress and port together are the unique identifiers of an endpoint. If a remote client connects to your server on port 80, other than the destination ip and port there is no other information that the networking layer has to identify which application, listening on port 80, deserves the packet. Given that provisioning multiple ip addresses is quite hard - impossible over a NAT - the only information thats really available to route the packet to the correct listener is the port. So you just can not have two applications listening on the same port.
Lastly websockets behave like native sockets, AFTER an initial HTTP negotiation. This means that, instead of using websocksify, you could teach your native server application to detect an attempt to connect by a websocket client and optionally perform the initial negotiation before going into 'native' mode.
Writing Websocket Servers gives a brief breakdown of what your native server would need to implement.
If you take a look of WebSocket, you will see that it's a protocol over TCP layer. Thus, your server socket can bind only once to the port 80 and it's up to you either you will use plain TCP, WebSocket or your custom protocol. There is no magic which enables switching from WebSocket to TCP and vice versa.
I was wondering, how multiple applications can use the same network port. AFAIK in TCP protocol 1 port is assigned to 1 socket connection. So how, for example, more than one internet browser can use ports 80/8080 at the same time?
Can I bind more than one socket to the same port? How can I do that in C++?
A socket connection is uniquely identified by a combination of its local IP:Port and remote IP:Port. Multiple apps can be bound to the same local IP:Port as long as they are each connected to a different remote IP:Port.
If a local IP:Port is already bound for listening (bind() and listen() have been called for it), other sockets can still bind() to that same local IP:Port but only if the SO_REUSEADDR (and on some platforms, SO_REUSEPORT) socket option is used. Otherwise, the bind() fails with an "already in use" error.
When multiple client sockets connect() to the same remote IP:Port, a local binding is typically not specified, which allows connect() to perform an implicit bind() to a random available local IP:Port to avoid conflicts with other connections. If bind() is explicitly called and succeeds, and then connect() is called to connect to a remote IP:Port that is already connected to the local IP:Port, connect() will fail.
A TCP port can only have a single socket listening for connections. When a connection is made via accept() or friends, a new socket is generated, that represents this connection, while the single original listening socket keeps listening.
In TCP, which is a stateful protocol, a connection is defined uniquely by the tuple [source_ip, source_port, dest_ip, dest_port] (look at Eugen Rieck's comment above). So theoretically, each client(or set of clients behind a NAT) could connect to the server on any 16-bit port number (minus typically the ports from 0-1023).
When a web server is listening on port 80(for example) for incoming HTTP connections, each time the client tries to send an HTTP request to the server, the client initiates a TCP connection over a different client port. So the answer to how multiple applications can use the same network port is by having a different port on the other side.
I have both a client and server application using UDP port 25565.
In order to run these on the same machine, because only one application may bind itself to port 25565, does this mean that it is necessary for me to use two separate ports for transmitting data between the applications?
What I have in mind is the following -
Client -> 25565 -> Server
Client <- 25566 <- Server
Is this the only solution or is there another way of handling this?
Your server application open a port and wait for client to connect.
Client need to know this port in advance so it can establish a connection to the desired service.
Client can use any available ports to initiate this connection (better to use ports > 1000).
The server sees in the incomming packet wich port the client is using, so it will send anwser to it. No need to specify it in your design.
After handshake the TCP/IP connection is then identified by these 4 values : server IP, server port, client IP, client port.
No other connection could have the same four values.
To answer your question. A TCP/IP connection is bi-directional, once established, the server can send data to the client and the other way around.
I would draw the scheme like this :
SERVER port 25565 <-> CLIENT port 25566 (or any other port)
Well, no. Only the server needs to listen on the port 25565 - the client will just connect to that port. There is no reason to specify which client the port should 'use' to connect to that port. Also, once the server has accepted the connection, the port can listen for other requests.
The whole point of separate UDP ports is to eliminate conflicts among applications listening to incoming packets. Changing one of these ports is probably the best solution.
However, if you really want both programs to listen on the same port you will need to use virtual network interfaces such as TUN/TAP (there is a Windows port). Then both applications will bind to the port with tha same number but on the different network interfaces.