Socket Error::Address Already In Use - sockets

I am facing this problem of Binding to socket.
1st instance works properly i.e.
socket() returns success and hence forth bind() and listen(), accept() and hence recv() - All fine till here.
2nd instance throw error while binding "Address already in use"
I went through all the post earlier on this and i dont see any specific solution provided on the same.
My code is as below :-
if((status = getaddrinfo(NULL,"8080",&hints,&servinfo))!=0){
ALOGE("Socket:: getaddrinfo failed %s\n",strerror(errno));
return NULL;
}
server_sockfd = socket(servinfo->ai_family, servinfo->ai_socktype, servinfo->ai_protocol);
if(server_sockfd == -1) {
ALOGE("Socket:: Scoket System Call failed %s\n",strerror(errno));
return NULL;
}
if ((setsockopt(server_sockfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(int))) < 0)
{
ALOGE("Socket:: setsockopt failed %s\n",strerror(errno));
return NULL;
}
ret = bind(server_sockfd, servinfo->ai_addr,servinfo->ai_addrlen);
if(ret!=0) {
ALOGE("Socket:: Error Binding on socket %s\n",strerror(errno));
return NULL;
}
This code runs on android platform.
I have properly closed each session before opening a new session as below :-
ret = shutdown(client_sockfd,0);
if(ret != 0)
ALOGE("Socket:: Shutdown Called%s\n",strerror(errno));
I tried with close as well but it did not work.
Surprisingly the error does not disappear even when we try to open the socket after long time (as per TIME_WAIT logic)
Could anyone please guide me to proper call or API or Logic(in code and not on command line apart from directly killing the process) to handle this situation ?

A socket is one half a channel of communication between two computers over a network on a particular port. (the other half is the corresponding socket on the other computer)
Error is very clear I suppose in this case. As mentioned Address already in use, so the the socket you are trying to connect in the second attempt is already used (port was already occupied) -> maybe due to first socket connection.
To investigate further check another SO question here and here

You can't share a TCP listening port between two processes even with SO_REUSEADDR.
NB shutdown() does not close a TCP session. It half-closes it. You have to close the socket.

Related

(LwIP) socket send() returns "Connection already in progress"

I'm maintaining an embedded system that uses LwIP. The relevant code is as follows (edited):
iobSocket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
connectRC = connect(socket, &serverAddress, sizeof(struct sockaddr));
FD_SET(socket, &fdset);
selectRC = select((socket) + 1, NULL, &fdset, NULL, &tv);
sendRC = send(iobSocket, dout, strlen(dout), 0);
This seems to work. When I remove the select() call, however, I get an error on the send() which sets errno to 119 or Connection already in progress. This error code isn't documented in the send() man pages.
Can someone tell me why the select() command is even necessary here, and why I might be getting an undocumented error without it?
Thank you.
Error code 119 is EINPROGRESS. It means the socket is operating in non-blocking mode 1, and the previous connect() operation hasn't finished yet, which is why the send() fails.
1: Which means, there must be more code that you are not showing, as sockets are normally in blocking mode when they are initially created, and require explicit code to put them into non-blocking mode, such as via fcntl(F_SETFL, O_NONBLOCK);.
Using select() to test the socket for writability allows your code to wait until the socket is actually done connecting and is ready for sending.
This is explained in the man page for connect():
RETURN VALUE
If the connection or binding succeeds, zero is returned. On error, -1 is returned, and errno is set to indicate the error.
ERRORS
The following are general socket errors only. There may be other domain-specific error codes.
...
EINPROGRESS
The socket is nonblocking and the connection cannot be completed immediately. (UNIX domain sockets failed with EAGAIN instead.) It is possible to select(2) or poll(2) for completion by selecting the socket for writing. After select(2) indicates writability, use getsockopt(2) to read the SO_ERROR option at level SOL_SOCKET to determine whether connect() completed successfully (SO_ERROR is zero) or unsuccessfully (SO_ERROR is one of the usual error codes listed here, explaining the reason for the failure).

sendto() fails for Custom UDP Protocol, using Seagull Protocol Traffic Generator

I'm brand new to working with networking, protocols, and sockets but this issue has been bothering me for a few days and I just cannot seem to find a solution. I am using Seagull, an open source multi-protocol traffic generator (source code), to create a client with a custom UDP. The unfortunate thing is that no one really keeps up with this software anymore and other people have had this problem but there are no solutions and it may be a bug in the generator software. I was able to write the XML scripts needed to run the traffic generator and when I ran the client on the local loopback (127.0.0.1) the generator worked fine and I was able to collect the packets and analyze them with Wireshark and they contained the correct data.
I'm now trying to use this client to send messages to a server on my local network (192.x.x.x) but Seagull keeps failing to send the messages. It's not a network issue because I've been able to ping the address with no packet loss. I've traced the source of the error back to the sendto() function, which keeps failing due to an invalid argument. I've stepped through the code using GDB when the destination was set to both the local loopback and the other IP and the arguments passed to the sendto() function were the exact same with the exception of different IP addresses in the sockaddr struct, which is of course expected. However, when I look at the registers after the system call in sendto() for the the one that contains the value for the length of the message length turns negative partway through the call and that is the value that is returned from the function call- this does not happen with the local loopback network. Here is the section of code that calls sendto() and fails:
size_t C_SocketWithData::send_buffer(unsigned char *P_data,
size_t P_size){
// T_SockAddrStorage *P_remote_sockaddr,
// tool_socklen_t *P_len_remote_sockaddr) {
size_t L_size = 0 ;
int L_rc ;
if (m_write_buf_size != 0) {
// Try to send pending data
if (m_type == E_SOCKET_TCP_MODE) {
L_rc = _call_write(m_write_buf, m_write_buf_size) ;
} else {
L_rc = _write(m_write_buf, m_write_buf_size) ;
}
if (L_rc < 0) {
SOCKET_ERROR(0,
"send failed [" << L_rc << "] [" << strerror(errno) << "]");
switch (errno) {
case EAGAIN:
SOCKET_ERROR(0, "Flow control not implemented");
break ;
case ECONNRESET:
break ;
default:
SOCKET_ERROR(0, "process error [" << errno << "] not implemented");
break ;
}
return(0);
where _write() is a wrapper for sendto().
I'm not really sure what is going on that causes it to do this and I've spent hours looking through the source code and tracing what is going on but everything seems normal up until the buffer length is modified in the system call. I've looked at the socket() initialization, binding, and other functions but everything seems fine. If anyone has any experience with Seagull or this problem, please let me know if you have had any suggestions. I've looked through almost every sendto() related question on this website and have not found a solution.
I am running the client on Ubuntu v 14.04 through a VM (Virtualbox) on a Windows 10 host, where I'm trying to send the messages. Thanks in advance!
I figured out the answer to this after days of debugging and looking through source code and I want to update this in case any poor soul in the future has the same problem. The original Seagull implementation always tries to bind the socket before calling send/sendto. In this case, since sendto automatically binds the socket I was able to remove the binding for this case.
Original implementation in C_SocketClient::_open (C_Socket.cpp Line 666):
} else {
L_rc = call_bind(m_socket_id,
(sockaddr *)(void *)&(m_remote_addr_info->m_addr_src),
SOCKADDR_IN_SIZE(&(m_remote_addr_info->m_addr_src)));
Edited Version:
} else {
L_rc = call_bind(m_socket_id,
/* UDP Does not need to bind first */
if(m_type != E_SOCKET_UDP_MODE) {
L_rc = call_bind(m_socket_id,
(sockaddr *)(void *)&(m_remote_addr_info->m_addr_src),
SOCKADDR_IN_SIZE(&(m_remote_addr_info->m_addr_src)));
} else {
L_rc = 0;
}
Now Seagull works and I am able to send my custom protocol! I opened a pull request for the original source code so that this can possibly be fixed.

Asio: 'Address Already In Use' on Bind, yet I can still Connect

I'm having what doesn't seem to be a problem but I don't understand the error. Basically, I've been trying to work on code that "gracefully" shuts down a tcp socket on both ends. At the end of my program, on both sides, I shutdown my sockets before closing them. On a quick restart, which is the thing I'm trying to solve, the much worse problem of crashing because the sockets are lingering on both sides doesn't happen anymore. The shutdown/then close seems to work on that front.
However, i get "Address already in use" still, which usually made it so that I couldn't connect. Now I'm able to connect after that error just fine. I've read a lot on the subject of graceful shutdown, reuse address, and the like. And I guess my question is, how, if the socket error'd on bind ("Address already in use"), after a successful open, is it possibly able to connect to the endpoint? In other words, if the address is actually already in use, how is the connection being made? Also, of note, reuse address doesn't work in this situation. Because I'm using the same socket settings, local/remote addresses and ip.
Failing to bind() the socket to an address does not invalidate the underlying socket. As such, the connect() operation will continue with an unbound socket, deferring to the kernel to bind to a local endpoint.
Here is a complete example demonstrating this behavior:
#include <boost/asio.hpp>
#include <boost/bind.hpp>
// This example is not interested in all handlers, so provide a noop function
// that will be passed to bind to meet the handler concept requirements.
void noop() {}
int main()
{
using boost::asio::ip::tcp;
// Create all I/O objects.
boost::asio::io_service io_service;
tcp::acceptor acceptor(io_service, {tcp::v4(), 0});
tcp::socket server(io_service, tcp::v4());
// Open socket1, binding to a random port.
tcp::socket socket1(io_service, {boost::asio::ip::address_v4::any(), 0});
tcp::socket socket2(io_service); // non-open
// Explicitly open client2, which will bind it to the any address.
boost::system::error_code error;
socket2.open(tcp::v4(), error);
assert(!error);
assert(socket2.local_endpoint().port() == 0);
// Attempt to bind socket2 to socket1's address will fail with
// an already in use error, leaving socket2 bound to the any endpoint.
// (e.g. a failed bind does not have side effects on the socket)
socket2.bind(socket1.local_endpoint(), error);
assert(error == boost::asio::error::address_in_use);
assert(socket2.local_endpoint().port() == 0);
// Connect will defer to the kernel to bind the socket.
acceptor.async_accept(server, boost::bind(&noop));
socket2.async_connect(acceptor.local_endpoint(),
[&error](const boost::system::error_code& ec) { error = ec; });
io_service.run();
io_service.reset();
assert(!error);
assert(socket2.local_endpoint().port() != 0);
}

infinite loop for listening to socket

I have an implementation where I listen to a port for events and do processing based on the input. I have kept it in a infinite loop. However it only works once and then I have to restart the program again. Does control never come back. Is this infinite loop a good idea?
Integer port = Integer.parseInt(Configuration.getProperty("Environment", "PORT"));
ServerSocket serverSocket = new ServerSocket(port);
LOG.info("Process Server listening on PORT: " + port);
while(true){
Socket socket = serverSocket.accept();
new Thread(new ProcessEvent(socket)).start();
}
Once you started the thread that handle the client, you also need to loop on a read function, because after you read a message, you will need to read the next messages. The accept() will return only once per client connection. After the connection is opened, everything happen in the thread, until the connection is closed.
Looping on accept() is a good idea, but the spawned thread must not exit as long as your client is connected. If you intentionally close the connection, then it should be fine if you make sure it is handled correctly on both sides, and the client needs to reopen the connection for further communication.

Using accept() and select() at the same time?

I've got an event-driven network server program. This program accepts connections from other processes on other hosts. There may be many short-lived connections from different ports on the same remote IP.
Currently, I've got a while(1) loop which calls accept() and then spawns a thread to process the new connection. Each connection is closed after the message is read. On the remote end, the connection is closed after a message is sent.
I want to eliminate the overhead of setting up and tearing down connections by caching the open socket FDs. On the sender side, this is easy - I just don't close the connections, and keep them around.
On the receiver side, it's a bit harder. I know I can store the FD returned by accept() in a structure and listen for messages across all such sockets using poll() or select(), but I want to simultaneously both listen for new connections via accept() and listen on all the cached connections.
If I use two threads, one on poll() and one on accept(), then when the accept() call returns (a new connection is opened), I have to wake up the other thread waiting on the old set of connections. I know I can do this with a signal and pselect(), but this whole mess seems like way too much work for something so simple.
Is there a call or superior methodology that will let me simultaneously handle new connections being opened and data being sent on old connections?
Last time I checked, you could just listen on a socket and then select or poll to see if a connection came in. If so, accept it; it will not block (but you may want to really should set O_NONBLOCK just to be sure)
you could use listen then use select or poll then accept
if (listen(socket_fd, Number_connection) < 0 )
{
perror("listen");
return 1;
}
fd_set set;
struct timeval timeout;
int rv;
FD_ZERO(&set); /* clear the set */
FD_SET(socket_fd, &set); /* add our file descriptor to the set */
timeout.tv_sec = 20;
timeout.tv_usec = 0;
rv = select(socket_fd + 1, &set, NULL, NULL, &timeout);
if (rv == -1)
{
perror("select"); /* an error occurred */
return 1;
}
else if (rv == 0)
{
printf("timeout occurred (20 second) \n"); /* a timeout occurred */
return 1;
}
else
{
client_socket_fd = accept (socket_fd,(struct sockaddr *) &client_name, &client_name_len);
}
I'd put a listener in separate process(thread) not to mess things up. And run a worker process on another to handle existing sockets. There's no need for non-blocking listener really. And no thread overhead running 2 threads.
It should work like that: you accept on your listener thread till it returns you a descriptor of client socket and pass it to worker which is doing all dirty read/write job on it.
If you want to listen several ports and don't want to hold one process per listener I suggest you set your socket in O_NONBLOCK and do someth like:
// loop through listeners here and poll'em for read
// when read is successful call accept, get descriptor,
// pass it to worker and continue listen
while(1){
foreach( serverSocket in ServerSockets ){
if( serverSocket.Poll( 10, SelectRead ) ){
clientSocket = serverSocket.Accept();
// pass to worker here and release
}
}
}