question related to sockets in network programming with C - c

There is a system call known as socket(); it creates a socket on the listening server.
What I want to understand is a server creates an IP+port combination.
Let us say telnet uses port 23.
Now when the client machines do connections then the port on which the server is listening then the connection there is not on port 23 in fact it is on a different port.My confusion is
on the server side also does the same thing happen.
For example I write a server to listen to port 23 then the connections which will be done on server side with different clients how are they differentiated because all of them will be on same port.So how can you make so many connections on the same server port.If some one uses
telnet (23) or ftp (21) or ssh (22) then many people can still login to the same service port on the server i.e. more than one connection for ssh by different users where as ssh is listening only at port 22.So what exactly does the socket do or how is a socket created?
UPDATE
I got what is explained.Depending upon the IP+port combination from the client machine where the connection originated rest of the things by the server side can be handled and I think this information probably is used by socket file descriptors. What I see is in connect() system call which we use as follows
connect(sockfd,(struct sockaddr *)&client_address,size_t);
we do pass on struct sockaddr * at the client end which has unique IP+port combination I think when server gets this in accept then things proceed.
What I want to know further is the argument at server side
accept(server_sockfd,(struct sockaddr *)&client_address,(size_t *)sizeof (struct sockaddr ));
Does it get that same client_address which from client side was passed on using connect()
system call? If yes then the socket_descriptors for the same server listening to many clients are different.What I want to know is how does the data structure at the server side is maintained when it accepts a request from the client.

The unique combination that identifies the connection is:
Source address and port
Destination address and port
In your example the destination address and port are the same for many connections, but each comes from a unique combination of source address and port.
Here is a brief tcpdump session of me connecting from my desktop to my server via FTP (port 21):
22:55:50.160704 IP 172.17.42.19.64619 > 172.17.42.1.21: S 2284409007:2284409007(0) win 8192 <mss 1460,nop,nop,sackOK>
22:55:50.160735 IP 172.17.42.1.21 > 172.17.42.19.64619: S 1222495721:1222495721(0) ack 2284409008 win 65535 <mss 1460,sackOK,eol>
22:55:50.160827 IP 172.17.42.19.64619 > 172.17.42.1.21: . ack 1 win 8192
22:55:50.162991 IP 172.17.42.1.21 > 172.17.42.19.64619: P 1:61(60) ack 1 win 65535
22:55:50.369860 IP 172.17.42.19.64619 > 172.17.42.1.21: . ack 61 win 8132
22:55:56.288779 IP 172.17.42.19.64620 > 172.17.42.1.21: S 3841819536:3841819536(0) win 8192 <mss 1460,nop,nop,sackOK>
22:55:56.288811 IP 172.17.42.1.21 > 172.17.42.19.64620: S 454286057:454286057(0) ack 3841819537 win 65535 <mss 1460,sackOK,eol>
22:55:56.288923 IP 172.17.42.19.64620 > 172.17.42.1.21: . ack 1 win 8192
22:55:56.290224 IP 172.17.42.1.21 > 172.17.42.19.64620: P 1:61(60) ack 1 win 65535
22:55:56.488239 IP 172.17.42.19.64620 > 172.17.42.1.21: . ack 61 win 8132
22:56:03.301421 IP 172.17.42.19.64619 > 172.17.42.1.21: P 1:12(11) ack 61 win 8132
22:56:03.306994 IP 172.17.42.1.21 > 172.17.42.19.64619: P 61:94(33) ack 12 win 65535
22:56:03.510663 IP 172.17.42.19.64619 > 172.17.42.1.21: . ack 94 win 8099
22:56:06.525348 IP 172.17.42.19.64620 > 172.17.42.1.21: P 1:12(11) ack 61 win 8132
22:56:06.526332 IP 172.17.42.1.21 > 172.17.42.19.64620: P 61:94(33) ack 12 win 65535
22:56:06.726857 IP 172.17.42.19.64620 > 172.17.42.1.21: . ack 94 win 8099
You can see the initial connection is 172.17.42.19.64619 <-> 172.17.42.1.21. Port 64619 is what the Windows 7 box happened to select as the source port when it made the outgoing connection. The two lines with S are the SYN packets going back and forth to establish the connection. Then I start the next connection and Windows just uses the next available port, 64620. The connection 172.17.42.19.64620 <-> 172.17.42.1.21 forms a new unique tuple of the items I listed at the top. Only the client's port is different, but that's enough. Each packet that arrives at the server to port 21 can be distinguished by the source port. Each packet from port 21 on the server arriving at the client can be distinguished by the destination port.

TCP connections are identified by 4 parameters:
local IP
local port
remote IP
remote port
So, even if two connections share the same local IP and port, the OS can differentiate between then because the remote IP and/or port are going to be different.

I will give you pseudo code from Qt to explain the matter. All TCP servers work in same way.
You first create a listening TCP server socket. When an incoming connection request arrives the operating system creates a new socket (your OS uses a different port than listening socket) and associates this new socket with the remote client for you. The TCP server socket continues to accept new connections and you resume your communication with the remote peer via the newly created socket.
tcpServer.listen(LocalHost, PORT);
connect(&tcpServer, SIGNAL(newConnection()),this, SLOT(NewConnection()));
//Callback that is called when server accepts a new connection
void NewConnection()
{
//Here you will have a new socket for communication with the client
//The tcpServer will continue listening to given port
QTcpSocket* connection = tcpServer.NextPendingConnection();
//Use your new connection to communicate with the remote client...
}
I hope this helps

Related

Question about parallel execution of printf in a multi-threaded program

I made a program that sends and receives files between two hosts through multi-thread.
The program works normally, but I am worried about the performance of this program.
I call printf quite a lot to show the information and transfer rate of the file to be transferred to the console. When proceeding without any separate action, there was a problem in that the printf of the two threads overlapped to cover each other's text.
The result I want
[TCP Server] 1 Client Connected: IP Address=127.0.0.1, Port Number=53423
FileName:HDT.exe, FileSize:79202368
Percent : 100.00%
[TCP Server] 1 client disconnected: IP Address =127.0.0.1, Port Number=53423
// The output of the upper part and the output of the lower part shall be simultaneously performed.
[TCP Server] 2 Client Connected: IP Address=127.0.0.1, Port Number=53425
FileName:HDT.exe, FileSize:79202368
Percent : 100.00%
[TCP Server] 2 client disconnected: IP Address =127.0.0.1, Port Number=53425
But there is this problem
[TCP Server] 1 Client Connected: IP Address=127.0.0.1, Port Number=53209
FileName:HDT.exe, FileSize:79202368
Percent : 90.63%% FileSize:79202368 Address=127.0.0.1, Port Number=53211
Percent : 90.63%
[TCP Server] 1 client disconnected: IP Address =127.0.0.1, Port Number=53209
// The transmission rate of two clients is also output to a cursor that outputs a transmission rate of one client, and the output is messed up.
Percent : 100.00%
[TCP Server] 2 client disconnected: IP Address =127.0.0.1, Port Number=53211
So I used CRITICAL_SECTION object like this
EnterCriticalSection(&cs);
cur.Y = thread_number * 6 + 2; // Cur is a COORD variable that stores zero as an x member.
SetConsoleCursorPosition(GetStdHandle(STD_OUTPUT_HANDLE), Cur); // Move the cursor position of the console before outputting for a smooth output.
// curProgress value is the size of the current file transferred.
// totalProgress value is stored by receiving the total file size from the other host before the file is transmitted.
printf("Percent : %2.2f%%", (curProgress / totalProgress) * 100.0f);
LeaveCriticalSection(&cs);
I also called EnterCriticalSection to notify the name of the file to be transferred or that the transfer has ended.
There is no problem with the operation of the program, but I think it is very bad for performance.
Is there really no way to efficiently print out multiple prints on different lines without using lock?
I also tried ANSI commands such as \033[;H, but the problem was not resolved.

socket connect function use 4 handshake?

i start a server listening on 9877
then i try to connect this server on the same machine
but when connnected
i captured 4 times round trip , confused
kernel version Darwin sifang.local 19.6.0 Darwin Kernel Version 19.6.0: Mon Aug 31 22:12:52 PDT 2020; root:xnu-6153.141.2~1/RELEASE_X86_64 x86_64
machine :macbook pro 2020
listening on lo0, link-type NULL (BSD loopback), capture size 262144 bytes
12:57:42.981579 IP localhost.51188 > localhost.9877: Flags [S], seq 4266424528, win 65535, options [mss 16344,nop,wscale 6,nop,nop,TS val 2395708763 ecr 0,sackOK,eol], length 0
12:57:42.981647 IP localhost.9877 > localhost.51188: Flags [S.], seq 3797230557, ack 4266424529, win 65535, options [mss 16344,nop,wscale 6,nop,nop,TS val 2395708763 ecr 2395708763,sackOK,eol], length 0
12:57:42.981656 IP localhost.51188 > localhost.9877: Flags [.], ack 1, win 6379, options [nop,nop,TS val 2395708763 ecr 2395708763], length 0
12:57:42.981661 IP localhost.9877 > localhost.51188: Flags [.], ack 1, win 6379, options [nop,nop,TS val 2395708763 ecr 2395708763], length 0
The first 3 lines of your tcpdump output are the 3-way handshake.
The fourth line is just the server sending out an ACK for some reason. Note that the first line is from port 51188 to port 9877 (client to server SYN), while the second line is from port 9877 to port 51188 (server to client SYN+ACK), the third line is from port 51188 to port 9877 (client to server ACK, ending the 3-way handshake), and the fourth line is from port 9877 to port 51188 (server to client, not a copy of the client to server ACK).
That doesn't happen with an Ubuntu server; this is probably either a difference between the macOS and Linux TCP implementations or in the SSH daemons being used.
I determined this by running tcpdump on a Linux machine and telnetting to port 22 on a Mac (so the loopback device isn't involved); the same four packets (3-way handshake plus extra ACK) showed up.
(No, packets sent on the loopback interface aren't seen twice when capturing traffic on all operating systems. They're seen twice if you're capturing traffic on Linux, but libpcap filters out the outgoing copy in its packet reading code. They are not seen twice on macOS - or other BSD-flavored OSes.
The capture mechanisms in Linux and macOS/*BSD are different:
Linux uses PF_PACKET sockets, which deliver both incoming and outgoing copies of packets on the loopback interface, but they look identical, with the same source and destination ports, so if libpcap didn't discard the outgoing copy, you'd see two identical packets, but libpcap discards the outgoing copy, so you see only one;
macOS/*BSD/Solaris 11/AIX use BPF devices, which deliver only one copy of packets on the loopback interface, so there's no copy to discard.)

3 sockets created for one libevent bind on Windows?

I'm writing a BitTorrent client to learn some more about networking, and I've got something that I'm struggling to Google for. As part of the BT spec, I need a server to listen for peer connections to my computer. In the win32 port, I have code like this to setup my server
struct sockaddr_in saServer;
struct hostent* localHost;
char* localIP;
// Get the local host information
localHost = gethostbyname("");
localIP = inet_ntoa(*(struct in_addr *)*localHost->h_addr_list);
saServer.sin_family = AF_INET;
saServer.sin_addr.s_addr = inet_addr(localIP);
saServer.sin_port = htons(6881);
struct evconnlistener *listener = evconnlistener_new_bind(base, accept_conn_cb, NULL,
LEV_OPT_CLOSE_ON_FREE | LEV_OPT_REUSEABLE, -1, (SOCKADDR*)&saServer, sizeof(saServer));
That seems to work, but if I look at netstat, I see the following,
BitTorrentClient.exe 6092 TCP hostname 50216 localhost 50217 ESTABLISHED
BitTorrentClient.exe 6092 TCP hostname 50217 localhost 50216 ESTABLISHED
BitTorrentClient.exe 6092 TCP hostname.home 6881 hostname 0 LISTENING
Why are there two other connections, one from port 50216->50217 and one looping back from 50217->50216? I was expected to have just one listening connection on port 6881. Is this a libevent quirk, or something more fundamental related to networking?
What can I search for to understand what the other two ports are used for?
This is most likely a result of libevent calling evutil_make_internal_pipe_ internally.
Libevent creates internal "pipes" for inter-thread communication and signal delivery using socketpair(2) on POSIX-compliant systems, whereas on Windows libevent has to resort to manually connecting two sockets together instead.

C - getaddrinfo returns "Servname not supported for ai_socktype"

So, after I got this error, I've been looking for an answer in here, almost everyone had a difficult way to fix this error but no one explained why this error occurs at all, so I don't find this question to be exactly duplicate.
I wrote a TCP socket in C and I used "getaddrinfo" function to make the socket work with hostnames, well it worked perfectly! you can find my codes on github.
but when I tried to create a UDP socket by "getaddrinfo" I got this error:
Servname not supported for ai_socktype
client.c
const char *host = argv[1];
const char *service = argv[2];
const char *string = argv[3];
struct addrinfo addrCriteria;
memset(&addrCriteria, 0, sizeof(addrCriteria));
addrCriteria.ai_family = AF_UNSPEC;
addrCriteria.ai_socktype = SOCK_DGRAM;
addrCriteria.ai_protocol = IPPROTO_UDP;
struct addrinfo *servAddr;
int ret = getaddrinfo(host, service, &addrCriteria, &servAddr);
if(ret != 0)
sysError(gai_strerror(ret));
I realized that when I give "service" a numeric input like 8080, no errors would return but when I use a string as service name like "tproxy" which points to port/8081, 'gai_strerror' returns mentioned error.
Obviously, gai_strerror says: "service names not supported for 'SOCK_DGRAM' socket types", but why? I mean the exact reason for "getaddrinfo" not supporting name services over UDP sockets?
Is there any other way to use service names with UDP sockets instead of port numbers? how?
TL;DR: There is no tproxy UDP port.
If you look up the tproxy service for UDP sockets in your service database,
getent services tproxy/udp
You get no output, because tproxy is not an UDP service. If you look at all tproxy services regardless of the protocol, getent services | grep -e tproxy, you'll see
tproxy 8081/tcp
which means that tproxy service is only defined for TCP protocol.
This means that if you ask getaddrinfo() for an UDP socket for service 8081, you will not find anything, because tproxy is only defined for TCP and not UDP.
Compare to the case where you ask for and UDP socket for xmpp-client service. At least my service database (getent services xmpp-client/udp) responds with
xmpp-client 5222/udp jabber-client
and indeed, getaddrinfo() happily provides the socket description for such UDP sockets (using xmpp-client or jabber-client as the service).
So, there are services like xmpp-client that do have both TCP and UDP ports defined. On my system, getent services | grep -e xmpp-client shows
xmpp-client 5222/tcp jabber-client
xmpp-client 5222/udp jabber-client
Because TCP and UDP are different protocols over IP, it makes sense that a service could use a different port number for TCP and UDP communications. So, it is unreasonable to assume that the service database should just return the same port numbers for TCP and UDP sockets.
In other words, you encounter the error because you mistakenly assume that because some service uses a TCP port, with a name registered in the service database, you should be able to use that name to specify an UDP port number, too.
TCP and UDP are separate protocols, and their port number spaces are separate. For example, TCP port 512 is used by the Unix exec r-service, whereas UDP port 512 is used by the biff mail notification service.
When a non-numeric value is given for the service parameter, it is looked up (on Linux) in the /etc/services file. This file maps a service name to a port/protocol. Below are some sample entries:
ssh 22/tcp
telnet 23/tcp
domain 53/tcp # name-domain server
domain 53/udp
The reason you're getting an error is because there is no UDP entry in your /etc/services file for "tproxy". Take a look at this file and look for an entry that does specify a UDP port such as "domain". That should have entries for both 53/tcp and 53/udp. If you pass in "domain" as the service name you should get a result back.

why i am getting Remote ip address 0.0.0.0 from recvfrom()?

I have a server listening on a port
The request is sent from my local client to the server running on my local pc.
Following is my code snippet
remote_len = sizeof(remote_addr);
if ((bytes=recvfrom(sockfd, buf, MAXBUFLEN , 0,
(struct sockaddr *)&remote_addr, &remote_len)) <= 0) {
exit(1);
}
printf("remote ip = %s\n",inet_ntoa(remote_addr.sin_addr));
When i print the ip i get 0.0.0.0 ??
Is this not the remote IP adrress which i am trying to print?
Edit : Its a TCP socket and i recevied buffer successfully.
See TCP recvfrom() doesn't store 'from' - apparently it's not supported for TCP. All you're seeing is the zero bytes that were originally there. That's why remote_len returns 0 - because no address was set.
That link is to windows related docs; I don't see that behaviour in the Linux man page, which says only "may be used to receive data on a socket whether or not it is connection-oriented", but at http://www.beej.us/guide/bgnet/output/html/multipage/recvman.html it says that recvfrom is for UDP. It's not mentioned in Harbison + Steele, unfortunately, and I can't find a copy of Unix Network Programming.

Resources