Socket dynamic binding to reduced range - c++

I have a C++ Server socket who runs within a virtual machine.
I have enabled the port forwarding for the port where the server socket is listening. However, due to dynamic binding I do not know on which port the communication will be done.
The OS i have within the virtual machine accepts dynamic binding in the following range:
cat /proc/sys/net/ipv4/ip_local_port_range
32768 61000
Is there a way (like a parameter to the bind/accept) in which i could specify to my server socket that he has to reduce this range to few ports ie: [35000 35010]
Cheers

A listening server socket must be bound to a specific port in order to accept client connections. On most platforms, you can bind() a socket to port 0 and it will bind to a random available port. But it is still binding to a specific port.
You cannot bind a socket to a range of multiple ports. If you need to listen on multiple ports, you must create a separate listening socket for each port and bind() them individually (ie one socket on port 35000, one socket on port 35001, one socket on port 35002, and so on, up to port 35010).
You cannot bind a socket to an available port within a given range, either. You can only bind to a specific port, or to port 0. If you need to listen on an available port within a given range, you must loop your call to bind(), starting at the lowest port and trying each port in sequence until either bind() is succeessful or the range is exhausted.

Related

Why does the UDP client port change on the UDP server

I've been following a simple UDP server/client tutorial found here, and I have a quick question about which port the client is connecting to the server.
From just viewing the code, it seems quite obvious that the server and client are connecting via port 8888:
Client.cpp
#define SERVER "127.0.0.1" //ip address of udp server
#define BUFLEN 512 //Max length of buffer
#define PORT 8888 //The port on which to listen for incoming data
Server.cpp
#define BUFLEN 512 //Max length of buffer
#define PORT 8888 //The port on which to listen for incoming data
However, when I actually run the server and the client, the server says the client connected port is always different:
First run (Server Log):
Note how the port changes from 8888
Second run (Server Log)
Note how the port changes again
Why would the connected ports change from 8888?
The comment in the client is incorrect. They just copied that line from the server, but they should have changed it to:
#define PORT 8888 //The port to send outgoing data to
The client and server both put the port in a sockaddr_in structure. The server uses this structure in its call to bind(), which sets the listening port. The client uses it in the call to sendto(), so it sets the destination port.
Since the client never calls bind() to set a specific local port, the source port is selected arbitrarily from the ephemeral port range. Each socket gets a different port to distinguish them.
If a fixed port were used as the client's local port, you wouldn't be able to have multiple clients on the same machine, since there would be no way to know which client should receive an incoming packet from the server. So fixed ports are typically used for servers, which random ports are used on the client.
When sending a UDP packet from one computer to another, there are two ports involved: the port that the receiving computer's UDP socket is bound to and is receiving on (8888 in your case), and the port that the sending computer is sending from. The port that you see changing is the port that the sending computer is using to send UDP packets from. Since the sending computer never explicitly chooses a UDP port to bind to (i.e. it never calls bind() with a non-zero argument), the sending computer's TCP stack simply picks a currently-available UDP port to implicitly bind the sending UDP socket to, and this port may be different each time the sending program is run.
8888 is the server port. The 5 digit port you see on logs are client ports created to eventually get data back from the server. This is an automatic and totally fine mechanism.

tcp socket, cannot bind to port - in use

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".

How multiple applications can use the same network port?

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.

How to Bind to the same UDP port on multiple interfaces

I have two network interfaces and am trying to bind to the same UDP port on both of them but I get an error when I try to bind to the second one, EADDRINUSE. When I bind to the sockets I pass a sockaddr* where I've setup the port and the unique IP address to use.
Do I have to use the socket option SO_REUSEADDR? Will this allow messages to be received on either socket or will they go to the socket that matches the IP address their bound to?
You can bind(2) one socket to INADDR_ANY for IPv4 or to in6addr_any for IPv6 (you don't have to, but that's the usual approach). That will make that single socket able to accept packets from all network interfaces on the box.
Then SO_REUSEADDR socket option will allow you to bind other sockets to more specific addresses, i.e. to individual interfaces, and same port.
Packets will be received on the socket that is bound to the address best matching the destination IP address of a given packet.

udp socket with c++ and windows API

I'm writting an UDP server for a game.
Do you know if is possible to have multisocket in UDP on one port ? or I must use dynamic port (one socket = one port) ?
thanks
It make no large sense to create multiple socket on one UDP port. UDP is not point 2 point protocol like TCP so using one "server" socket bind to specific port you can handle hundreds of clients.
See Using SO_REUSEADDR...:
Using SO_REUSEADDR
The SO_REUSEADDR socket option allows a socket to forcibly bind to a
port in use by another socket. The second socket calls setsockopt with
the optname parameter set to SO_REUSEADDR and the optval parameter set
to a boolean value of TRUE before calling bind on the same port as the
original socket. Once the second socket has successfully bound, the
behavior for all sockets bound to that port is indeterminate. For
example, if all of the sockets on the same port provide TCP service,
any incoming TCP connection requests over the port cannot be
guaranteed to be handled by the correct socket — the behavior is
non-deterministic. A malicious program can use SO_REUSEADDR to
forcibly bind sockets already in use for standard network protocol
services in order to deny access to those service. No special
privileges are required to use this option.
Bonus reading: What exactly does SO_REUSEADDR do? .
Sure you can have multiple UDP sockets on one port if SO_REUSEADDR is specified via setsockopt.
However, I doubt that what you really need is using one UDP socket to communicate with multiple clients, which is also feasible. UDP is not connection-oriented, UDP APIs like sendto and recvfrom could distinguish different peers on one socket.