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.
Related
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.
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.
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".
I am working on an application that will receive RTP packets from another local service over UDP. Early in the protocol, I receive a message with the IP address from which I'll be receiving these RTP packets, but the port number will be given as 0 (zero) ... I'm to open my UDP socket using an ephemeral port. My response to the given message will contain the actual port I've opened so the sender can know where to direct the packets.
My networking library is an implementation of sockets with boost::asio. Where can I find clear information on how to open such a socket without specifying a non-zero port i.e. use an ephemeral port? Searching the boost docs for "ephemeral" doesn't give me networking results.
Of course, I'm open to seeing an actual example, but finding good documentation would also be just fine.
Thanks.
I would question using ephemeral ports like that, but ... - you can bind your UDP socket to port 0, then use local_endpoint() to retrieve actual port assigned by the OS.
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.