Can a socket server created with socket(AF_UNIX, SOCK_STREAM, 0) write to itself?
I'm asking this becouse the first send is ignored if it was from the same server to the same server, but if it a client is the one who sent it then it not ignored.
why does that happen and how to not ignore the first send from server?
Related
The following TCP/IP client code works as expected if the server is running before I call this function. If the server is not running, connect() returns immediately and prints errno = 111, connection refused. I ended up placing the call to connect() in an infinite while-loop with a 1-second delay between calls. When the server is up, the code connects and exits the loop. Q: Is this how connect() in blocking mode supposed to work? If so, is there a way to configure connect() to wait until the server is running before returning?
int socket_connect(const char *host, int port, int timeout)
{
struct sockaddr_in sa;
struct hostent *hp;
int sockfd = -1;
hp = gethostbyname(host);
if (hp == NULL)
{
return -1;
}
sa.sin_family = AF_INET;
sa.sin_port = htons(port);
sockfd = socket(AF_INET, SOCK_STREAM, 0);
int status = connect(sockfd, (struct sockaddr *)&sa, sizeof(sa));
if (status != 0)
{
close(sockfd);
printf("errno = %d\n",errno);
return -2;
}
...
connect has a single task - establish a connection to a (remote) server socket. This server socket is expected to exist for this, i.e. the server application holding this socket is expected to be running. And the server system is expected to be reachable. connect is just doing internally the TCP handshake, i.e. it sends a SYN packet and wait for the SYN+ACK for the server.
If the server application is running and listening on the server socket and if the server system is reachable (i.e. no connectivity loss or firewall blocking connection) then the server system will respond quickly with SYN+ACK and connect will succeed in a short time.
If the server application is not running or not (yet) listening on the server socket, then the server system will explicitly reject the connection attempt - resulting in connect returning with "connection refused". This is also the case if there is a firewall explicitly rejecting the connection or if the server is running out of resources, like if the listen queue for the server socket is full.
If instead there is a loss of connectivity or if there is a firewall which will block connections attempts by simply dropping the packets before they reach the server system, then connect will internally try to reach the server by repeatedly retrying sending the SYN to get a response back. After a while connect will give up and consider the connection attempt failed with "timed out".
Let's say we have a server that can accept multiple clients. First, it has to create a socket, then bind it with a port and an IP and finally listen to requests for connection from clients. After accept()ing a connection with a client, the server creates a new socket to communicate with the specific client. My question is whether or not the client is going to send its data to the same port it sent its initial request to, and if not how does it know where to send it?
A socket connection is uniquely identified by a tuple of [Protocol, Local IP, Local Port, Peer IP, Peer Port].
A TCP server creates a listening socket with a tuple of [TCP, Listen IP, Listen Port, 0, 0]. When a client requests to connect to a server, the network routes the request to the specified IP/Port. The receiving device then routes the request to a matching listening socket, performs a 3way handshake with the client, and puts it into a queue. Later, when accept() is called, it extracts the next pending client from the queue and returns a new socket identified with a tuple of [TCP, Listen IP, Listen Port, Client IP, Client Port]. Because of this, a single listening socket can accept multiple Clients from different Client IP/Port combinations.
A TCP client creates a connecting socket with a tuple of [TCP, Local IP, Local Port, 0, 0]. When the 3way handshake is complete, the socket's tuple is updated to [TCP, Local IP, Local Port, Server IP, Server Port]. Because of this, a Client can connect separate sockets to different Servers at differing Server IP/Port combinations.
All subsequent data exchanges use these tuples.
Data sent out from a Client's connecting socket will be sent to the associated Server IP/Port and stored in the buffer of the accepted Server socket whose tuple matches both the Client and Server.
Data sent out from a Server's listening socket will be ignored, since there is no associated Client.
Data sent out from an accepted Server socket will be sent to the associated Client IP/Port and stored in the buffer of the connected Client socket whose tuple matches the Client and Server.
Generally There is always a default port allotted for each kind of communication.Operating System may kept it open or close ,it can be checked .
Let's say for FTP connection, There is a separate port allotted for handshake,It don't matter how many new FTP connection are being requested, all new connection will go to that same port , Once handshake is completed data exchange is done via another port, Even if we don't specify port. If Network manager has Port List entries earlier it will request to the same port.
Example for SSH
if you request for
ssh -X <IP>
Even if you don't mention port , Your system know which port to request for and at server side there is always some port open who will be listening to your request and based on data you send while handshake it will continue listening or block you.
Bonus is you can open your custom port at server side who will be listening to your request. TCP implementation by default declare which port will be used for what kind of communication.
The client connects with a source IP and port to a server with a destination IP and port. After accept exactly the same IP and port on both sides are continued to be used for data exchange as for the establishment of the connection.
I'm implementing my own TCP server. So far I can make a connection, that works fine, I can connect to any client. However when I want to send or receive messages from the client it goes wrong. The following is a snippet of the last part of my server, where I want to send the message WeLcOmE to my client (I'm using C programming language & Linux as the OS):
// Accept a connection request
int clientAddress = sizeof(client_address);
int new_socket = accept(door_socket, (struct sockaddr *) &client_address,
&clientAddress);
if (new_socket < 0)
perror("ERROR on accept");
// Receive data from socket, send data to socket
char buff[8] = "WeLcOmE";
send(new_socket, buff, sizeof(buff), 0);
// Close socket
close(new_socket);
close(door_socket);
return 0;
Running my server with a Filezilla Client this is what I get:
Status: Resolving address of ubuntu
Status: Connecting to 127.0.1.1:3471...
Status: Connection established, waiting for welcome message...
Response: WeLcOmE
Error: Could not connect to server
Status: Waiting to retry...
Status: Resolving address of ubuntu
Status: Connecting to 127.0.1.1:3471...
Status: Connection attempt failed with "ECONNREFUSED - Connection
refused by server".
Error: Could not connect to server
Running my server with the ftp Linux built-in client I get:
ftp> WeLcOmE421 service not available remote server has closed connection
I don't understand why is this happening. Any help is appreciated.
As you have yourself stated, you have implemented a "TCP" server. All the server does is that it sends the "WeLcOmE" string to any TCP client that connects to the server.
If you connect with an FTP client to the server, the client gets the "WeLcOmE" string, and as that does not conform to the FTP protocol specification, the client errors.
The same would happen, if you connect with any other client that uses a specific protocol, e.g. a web browser [HTTP], a terminal client [SSH or Telnet], etc.
Now the question is, what you are trying to achieve:
Either you want to implement an FTP server. For that you need to read the FTP specification and implement your server according to it. That's an immense task and in general you do not want to do that. You better take an existing implementation. Either an FTP server library and build your custom FTP server on it. Or take a complete open source FTP server and customize it to your needs.
Or you just play with your toy TCP server and you want to test it. For that use any TCP client that can work in "raw" mode by reading from the socket and just displaying what it gets, without trying to interpret the data in any way. You can use PuTTY in a "raw" connection mode. See section Making raw TCP connections in PuTTY documentation.
I am new to socket programming.Please provide me some techniques to run the server socket infinitely even if I close the client socket using close(clientfd) in C programming (the server has to wait in accept()for the next client connection even if the current connection is closed ). Also kindly help me how the close() in client side affects the socket in server side.
Can I create 2 UDP sockets on the same client machine (but will be used in 2 different threads) to connect to a server? One thread sends datagrams to and the other receives datagrams from the server. Are these the correct steps:
create a sockaddr_in for the server's given address and UDP port.
create a socket and connect it to the server's sockaddr_in. This
is the sending socket.
Create another socket, assign a port and
sent the port number to the server.
Thank you.