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.
Related
I have a UDP server, but I have no UDP capability on client side. Is there a way to send packet via TCP so that UDP server can receive it normally? UDP server cannot be transformed into TCP server.
Reason for wanting to do this is that I'm using a SOCKS5 proxy that does not support UDP associate capability, but I have to use that proxy.
No. The UDP server cannot complete the 3-way handshake required for TCP. If you have IP-raw sockets, it is actually easier to implement UDP on top. However it seems extremely unlikely that you don't have a UDP-stack.
When you talk about "no UDP capability" do you mean the client has no UDP-stack, or is he just behind some firewall that blocks UDP? In the latter case use a proxy.
No, UDP server will not going to accept TCP packets at all (it's a different protocol, so network stack will never propagate those to the application).
If you have to use SOCKS5 proxy, the only way to connect to the said server is by using another proxy-like application, which will stand beyond SOCKS5, accept TCP connections (initiated by app behind SOCKS5 proxy) and retransmit data as UDP.
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.
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".
When facing below situation what debugging tools/skills can we use to solve the problem? See the flow, we use port forwarding in NAT2 whose type is Symmetric so that the client can communicate with Server. When session between client and server is established, the client can send files to the server via TCP connections. The upload bandwidth is around 2Mbit/s.
The issue is while the client is uploading files to server, we found at some point all the TCP connections will be blocked, the server can't receive any packets from those TCP connections anymore so that all the tcp connections will be dropped by server application because of timeouts. NAT2 is a SO simple router that we can't capture packets from it, to get rid of this issue what can we do?
Client ----- NAT1 ---Internet----- NAT2 ----- Linux Server
UPDATE
Problem also exists in below topology. In this topology, the NAT between client and Linux server is also the NAT2 other than a different one, because the client use DNS name to access Linux server, thus all packets from client will go through NAT2 to the internet, but will come back to NAT2 again and be sent to LINUX Server by Port Forwarding in NAT2.
Here is another question: if there is some application persisting in sending packets to the forwarding port (we set Port Forwarding in NAT2, and suppose the port Number is PortN), then can it cause all the tcp connections which receive packets via this PortN to be blocked or to receive no packets within 3-5 minutes?
Client ----- NAT2 ---Internet----- NAT2 ----- Linux Server
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.