This question already has answers here:
Client Server multiple connections in C
(3 answers)
How to handle multiple socket client through server in c linux
(3 answers)
Closed 5 months ago.
I am a novice UNIX socket programming learner and I would like to inquire some advice on writing a server that can handle both TCP connections and UDP datagrams on the same port with a server written in C.
I was asked to write a server that could take multiple commands from clients, with the type of transport layer protocol varying between TCP and UDP based on the command sent by the client. For example, if users type a "login" command then it must be sent to the server through TCP, while a "register" command must be sent through UDP.
The typical behavior of a client is listed as below:
1. Create TCP and UDP sockets
2. Connect the TCP socket to the server
3. Based on the commands entered by the user, the message from the cilent must be sent to the server with a specified protocol. (Example: TCP for "login", etc... ; UDP for "register", etc...)
4. After the user enters the "exit" command, close both TCP and UDP sockets.
The partial workflow of the server I already written include:
1. Create TCP and UDP sockets
2. Bind TCP and UDP sockets to the same port
3. Listen with the TCP socket
4. Accept the TCP connection from a client
5. ???
The uncertainties that I hold are steps starting from 5. Apparently if it were simply a TCP server I could just read from and write into the new TCP socket created with the accept() function call. However now that I have two potential sources of receiving the next message from the client, I do not know what to do to handle them both.
Thank you !
Related
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.
Please assume that we can distinguish packets of different TCP connections from each other, if so then can we accept multiple TCP connections on the only one socket in server side? I know that the server binds on a socket and when accepting new connection assigns a new socket to new connection. Would I override ACCEPT systemcall?
Please assume that we can distinguish packets of different TCP connections from each other
You can't assume it. There are no 'packets' visible to the application over a TCP connection. A TCP connection provides a byte stream. You can't guarantee that the next thing you read will be say a message header telling you which client the message is from.
I'm creating a socket table from a network composed of 2 hosts. They have a p2p connection and they're working with tcp protocol. Do I have to create a welcoming socket in both of the hosts (as they act like servers)? And a receiving socket as well as a sending socket for each host? Or just one for sending/receiving would be ok?
Each host will need a listening socket on which it will accept new connections. It will also need one socket for each inbound TCP connection (returned from the accept call when it accepts an inbound connection) and one for each outbound TCP connection (returned from the socket call before calling connect to make the outbound connection).
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).