0

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?

Community
  • 1
  • 1
Guhan S
  • 19
  • 2
  • 1
    I'm not quite sure what you're asking. Are you confusing source and destination ports? – CodeCaster Jan 06 '16 at 12:58
  • Can you provide pointers on what is supposed to happen in a simple client-server application? Perhaps then, I will try to match with bitcoin. – Guhan S Jan 06 '16 at 13:02
  • First Google hit on "tcp source destination port": http://stackoverflow.com/questions/21253474/source-port-vs-destination-port – CodeCaster Jan 06 '16 at 13:03

2 Answers2

2

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.

Philip Stuyck
  • 7,344
  • 3
  • 28
  • 39
  • Thanks! I get it now. But my question is actually specific to bitcoin application. The server is listening in 18333 port. Lets say many client make connections to that server via the same destination port. So can the port 18333 at server end, be used to send/receive data? Is it not locked down to only listen connections? But somehow bitcoin is communicating and listening via the same port – Guhan S Jan 07 '16 at 03:20
  • No because each connection has its own sockets, and there still is one listening socket. which in the explanation above is indicated with the +1. If there are no connections, you only have the listening socket. And it will be used only to listen for new incoming connections. – Philip Stuyck Jan 07 '16 at 20:54
0

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.

Danny_ds
  • 11,201
  • 1
  • 24
  • 46
  • of course port numbers are not part of the ip header, but either the tcp header or udp header. The ip addresses are part of the ip header. I guess that is what you mean, but I would recommend adapting this answer to avoid downvotes. – Philip Stuyck Jan 06 '16 at 14:57
  • @PhilipStuyck - Yes, of course - updated now, thanks. – Danny_ds Jan 06 '16 at 15:36