I Work with a Hardware and I can ping with it.I write a TCP server App that listen to special port and and special IP (My hardware Ip). the hardware send data in ip and port that I don't know, so how can I get data from my hardware with TCP protocol?
Related
I need to forward an unidirectional stream of udp packets from one side to an HTTPS connection on the other end.
I can potentially solve it using python, but this server should be able to forward large amount of traffic so I would like to rely on Nginx for this task.
can Nginx do such a thing?
What I tried
I tried:
stream {
server {
listen 9990 udp;
proxy_pass localhost:9995;
}
}
which forward correctly UDP packets.
I tested it running 2 servers
nc -u -l 9995 # listen on udp port 9995
nc -u localhost 9990 # send packets to nginx listening on udp port 9990
this test worked when both connections are udp. my goal to listen on TCP on port 9995 instead of udp, currently I couldn't do it with nginx.
Why?
additional context, not part of the question
I have a wire that can transfer packets only in one direction. so TCP connection can't be established. the other end requires https connection, so I can go around this by another server in the middle that will accept udp socket on one end and http/tcp socket on the other end, that will forward any udp packet coming from one end as an HTTP msg over TCP with the other end
This question already has answers here:
Does the port change when a server accepts a TCP connection?
(3 answers)
Closed 4 years ago.
Hi I'm just a newbie in networking,
just want to ask, is welcoming port of welcoming socket on a server the same as listening port?
For example, we all know HTTP use port 80, so is port 80 the welcoming port of the web server to initialize TCP's three way handshake? and actual port number of connection socket (for transmission of http message) can be arbitrary number assigned by the server?
From the accept manpage:
The accept() system call is used with connection-based socket types
(SOCK_STREAM, SOCK_SEQPACKET). It extracts the first connection
request on the queue of pending connections for the listening socket,
sockfd, creates a new connected socket, and returns a new file
descriptor referring to that socket. The newly created socket is not
in the listening state. The original socket sockfd is unaffected by
this call.
"welcome" port is the listening port. All client initiate connections to webserver "listening" on port 80 ( clients are "welcome" on port 80). The connection in ESTABLISHED state will have a different socket fd than listen fd.
is welcoming port of welcoming socket on a server the same as listening port?
The port on the server stays the same, i.e. 80 for all the clients even after the three-way handshake.
I guess what you really ask is how sever distinguish simultaneous client connections.
Usually network sockets use unique 4-tuples to identify the connection, i.e. source IP, source port, destination IP, destination port: https://en.wikipedia.org/wiki/Network_socket#Socket_pairs
So the destination IP and port stays the same for all the clients (i.e. server's IP and port 80) but the source IP and ports are different. That is how server distinguish different connections to the same port 80.
actual port number of connection socket (for transmission of http message) can be arbitrary number assigned by the server?
The destination port stays the same, i.e. 80 as described above. Instead each client selects its unused source port before establish the TCP connection.
RELATED POST
The post here In UNIX forum describes
The server will keep on listeninig on a port number.
The server will accept a clients connect() request using accept(). As soon as the server accepts the client request, the kernel allocates a random port number for the server for further send() and receive(), since the same port number on the server can't be used for sending as well as listening, and the previous port is still listening for new connections
QUESTION
I have a server application S which is constantly listening on port 18333 (this is actually bitcoind testnet). When another client node C connects with it on say 53446 (random port). According to the above post, S will be able to send/receive data of 'C' only from port 53446.
But when I run a bitcoind testnet. This perfectly communicates with other node with only one socket connection in port 18333 without need for another for sending/receiving. Below is snippet and I even verified this
bitcoin-cli -testnet -rpcport=16591 -datadir=/home/user/mytest/1/
{
"id": 1,
"addr": "178.32.61.149:18333"
}
Can anyone help me understand what is the right working in TCP socket connection?
A TCP connection is identified by a socket pair and this is uniquely identified by 4 parameters :
source ip
source port
dest ip
dest port
For every connection that is established to a server the socket is basically cloned and the same port is being used. So for every connection you have a socket using the same server port. So you have n+1 socket using the same port when there are n connections.
The TCP kernel is able to make distinction between all these sockets and connections because the socket is either in the listening state, or it belongs to the socket pair where all 4 parameters are considered.
Your second bullet is therefore wrong because the same port is being used as i explained above.
The server will accept a clients connect() request using accept(). As
soon as the server accepts the client request, the kernel allocates a
random port number for the server for further send() and receive().
On normal TCP traffic this is not the case. If a webserver is listening on port 80, all packets sent back to the client wil be over server port 80 (this can be verified with WireShark for example) - but there will be a different socket for each connection (srcIP:port - dstIP:port). That information is sent in the headers of the network packets - IP and protocol code (TCP, UDP or other) in the IP header, port numbers as part of the TCP or UDP header).
But changing ports can happen when communicating over ftp, where there can be a control port (ususally 21) and a negotiated data port.
When I open TCP with the server (on 7 layer of OSI), the layer 5 create socket with port number and IP.
I want to know if this socket include my IP/the server IP, and my (random) port or the server port (e.g. 80 for HTTP)
And when I open TCP with server we open TCP together
So it's mean we have common socket?
When I open TCP with the server (on 7 layer of OSI)
Forget about OSI. It is obsolete, and TCP/IP doesn't follow it. It has its own layer model.
The layer 5 create socket with port number and IP
TCP creates it at the TCP layer.
I want to know if this socket include my IP/the server IP, and my (random) port or the server port (80 for HTTP for ex.)
All of the above.
And when I open TCP with server we open TCP together So it's mean we have common socket?
No. A socket is an endpoint of a connection. There are two ends, and two sockets.
TCP is a Layer 4 as it is called - or a Transport Layer, so ignore the OSI model for the time being.
Generally - 'a socket' is just an end point without any identity. The socket gets it's identity when you bind to an address or connect to an address.
When you bind to an address - you only get your local port and local IP address in it's end point, but not the remote IP and port address. As such such socket is not very useful unless you listen on it. This is typically done on the server. Also note that you can bind to 'All Addresses on the machine' and then you really don't have any one end-point per se.
When you connect to a server (a TCP server # port 80 say), your OS TCP/IP stack makes use of a local IP address and chooses a random port to connect to a sever socket (like say one listening above). This is when all the 4 addresses come into picture. This socket is a connected socket and all 4 values will be present.
First of all, is there any problem with using both UDP and TCP on the same server?
Secondly, can I use the same port number?
Yes, you can use the same port number for both TCP and UDP. Many protocols already do this, for example DNS works on udp/53 and tcp/53.
Technically the port pools for each protocol are completely independent, but for higher level protocols that can use either TCP or UDP it's convention that they default to the same port number.
When writing your server, bear in mind that the sequence of events for a TCP socket is much harder than for a UDP socket, since as well as the normal socket and bind calls you also have to listen and accept.
Furthermore that accept call will return a new socket and it's that socket that you'll then have to also poll for receive events. Your server should be prepared to continue accepting connections on the original socket whilst simultaneously servicing multiple clients each of which will be triggering receive events on their own sockets.
Firstly,there is no problem using both tcp and udp on the server.
Secondly,we can have both UDP and TCP requests on same port ,because each request is identified by a quintuple contained by source IP ,Destination IP, Source Port, Destination Port, PROTOCOL(as protocol can be TCP or UDP).