I have a loop which keeps writing data to a client through TCP/IP. The connection is opened as follows:
newsockfd = accept(sockfd,
(struct sockaddr *) &cli_addr,
&clilen);
The following line is executed continuously in a loop (with sleep of 0.1 sec) in order to write the data to the client:
n = write(newsockfd,data.c_str(),data.length()+1); //+1 to include NULL in null terminated string
if(n>=0)
{
cout<<"success"<<endl;
}
else
{
cout<<"Fail"<<endl;
close(newsockfd);
newsockfd = -1;
}
I want the server to become reading for receiving a new connections if the connection is broken for any reason. So if writing fails, I get ready again to accept a new connection with the first command.
My problem is the following: the method succeeds for the first time, so if the connection is broken from the client, write() returns a negative number and I know immediately that the connection has a problem, so I close it and expect a new one. The server receives the new connection, but at the next time when using write(), the program crashes immediately.
Why does this happen? Please help, I'm new in TCP/IP stuff.
Please ask for more information if you require it.
Requested from helpers:
Stack trace:
Error: signal 13:
/mnt/hgfs/Dropbox/common_src/LinuxTCP/Server/ServerLinux-build-desktop-Qt_4_8_1_in_PATH__System__Release/ServerLinux[0x402155]
/lib/x86_64-linux-gnu/libc.so.6(+0x364a0)[0x7ffc57ac04a0]
/lib/x86_64-linux-gnu/libpthread.so.0(write+0x10)[0x7ffc5836dcb0]
/mnt/hgfs/Dropbox/common_src/LinuxTCP/Server/ServerLinux-build-desktop-Qt_4_8_1_in_PATH__System__Release/ServerLinux[0x4023b6]
/mnt/hgfs/Dropbox/common_src/LinuxTCP/Server/ServerLinux-build-desktop-Qt_4_8_1_in_PATH__System__Release/ServerLinux[0x401b54]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7ffc57aab76d]
/mnt/hgfs/Dropbox/common_src/LinuxTCP/Server/ServerLinux-build-desktop-Qt_4_8_1_in_PATH__System__Release/ServerLinux[0x402081]
Variable definitions: it's a class:
Body:
int sockfd, portno, n;
struct sockaddr_in serv_addr;
struct hostent *server;
Constructor starts the stuff:
LinuxTCPServer::LinuxTCPServer(int port, bool nonblocking)
{
if(nonblocking)
sockfd = socket(AF_INET, SOCK_NONBLOCK | SOCK_STREAM, 0);
else
sockfd = socket(AF_INET, SOCK_STREAM, 0);
if (sockfd < 0)
error("ERROR opening socket");
bzero((char *) &serv_addr, sizeof(serv_addr));
portno = port;
serv_addr.sin_family = AF_INET;
serv_addr.sin_addr.s_addr = INADDR_ANY;
serv_addr.sin_port = htons(portno);
if (bind(sockfd, (struct sockaddr *) &serv_addr,
sizeof(serv_addr)) < 0)
error("ERROR on binding");
listen(sockfd,5);
clilen = sizeof(cli_addr);
}
Assuming Linux >= 2.2, replace this:
n = write(newsockfd,data.c_str(),data.length()+1);
with this:
n = send(newsockfd, data.c_str(), data.length()+1, MSG_NOSIGNAL);
send(2) will then return -1 with errno set to EPIPE, rather than generating a fatal SIGPIPE. Alternatively, ignore SIGPIPE.
When you receive the SIGPIPE, the connection behind newsockfd has been broken. We don't have enough code to reproduce the problem, client and server, so it's rather moot to say what might actually be wrong. However, converting SIGPIPEs to EPIPEs will at least give your server a chance to handle the broken connection.
Your stack trace indicates that the program is crashing with signal 13, which means you have a broken pipe.
That would indicate that your connection is broken, but you are still trying to write to it. See this thread for why that might causes the broken pipe error: What causes the Broken Pipe Error?
Now, on how to solve the issue, I suspect you're not actually getting a proper connection setup on your 'accept' call. Make sure you check the status of your 'accept' call before calling write.
The problems that are causing your accept call to fail are likely on the other side of the connection I think.
Related
I'm trying to build a block that acts as server and client to send and receive data (2 duplicate versions in 2 different computers) through a TCP connection.
This is what I did and I'm trying to test using the windows commandd line "netstat -ab" to try to find the tcp connection but I can't find it.
Apart from the given error, what am i doing wrong?
bool IPTunnel::runBlock(void) {
int ready =
inputSignals[0]->ready(); // int ready2 = inputTCPConnetion[0]->ready();
// server
SOCKET sockfd, newsockfd;
int portno;
socklen_t clilen;
char buffer[256];
struct sockaddr_in serv_addr, cli_addr;
SOCKET n;
// create a socket(int domain, int type, int protocol)
sockfd = socket(AF_INET, SOCK_STREAM, 0);
if(sockfd < 0) printf("\n ERROR opening socket");
// bzero((char *)&serv_addr, sizeof(serv_addr));
portno = 5500;
serv_addr.sin_family = AF_INET;
char ipad[10] = "127.0.0.1";
serv_addr.sin_addr.s_addr = *ipad; // INADDR_ANY;
serv_addr.sin_port = htons(portno);
// if (bind(sockfd, (struct sockaddr *) &serv_addr, sizeof(serv_addr)) < 0)
auto sd = bind(sockfd, (struct sockaddr*)&serv_addr, sizeof(serv_addr));
// if (sd < 0)
// printf("\n ERROR on binding");
listen(sockfd, 5);
clilen = sizeof(cli_addr);
newsockfd = accept(sockfd, (struct sockaddr*)&cli_addr, &clilen);
if(newsockfd < 0) printf("ERROR on accept");
printf("server: got connection from %s port %d\n",
inet_ntop(serv_addr.sin_family, &ipad, buffer, clilen),
ntohs(cli_addr.sin_port));
send(newsockfd, "Hello, world!\n", 13, 0);
// bzero(buffer, 256);
n = _read(newsockfd, buffer, 255);
if(n < 0) printf("ERROR reading from socket");
printf("Here is the message: %s\n", buffer);
while(true) {
}
// close(newsockfd);
// close(sockfd);
return 0;
}
This is the error that gives: Unhandled exception at 0x00007FFE5031B7EC (ucrtbased.dll) in ip_tunnel.exe: An invalid parameter was passed to a function that considers invalid parameters fatal.
in the _read function...
Well, this line is definitely wrong:
serv_addr.sin_addr.s_addr = *ipad; //INADDR_ANY;
If you want to receive incoming TCP connections on the loopback device, you should do something more like this:
serv_addr.sin_addr.s_addr = inet_aton("127.0.0.1");
(or if you want them to be received from any connected network device, specify INADDR_ANY instead)
Also, make sure you called WSAStartup() at the beginning of your program, Windows sockets won't work correctly if you haven't done that.
One last nitpick:
while(true){}
is not a good way to pause execution of your program. For one thing, it will typically spin a CPU at 100% usage, which is very inefficient, and for another, it invokes undefined behavior according to the C++ standard.
A better way to do get that behavior would be something like:
while(true) {Sleep(1000);}
Also this part is wrong/weird:
SOCKET n;
[...]
n = _read(newsockfd, buffer, 255);
... in that _read doesn't return a SOCKET, it returns an int. I think you meant to declare int n; instead.
One last potential problem: if your call to bzero(buffer, 256); is commented out, then it's quite possible for buffer to contain no zero-bytes after the _read() call returns, in which case your printf("Here is the message: %s\n", buffer); call afterwards could read right past the end of the buffer array and out into the wild blue yonder of other memory, potentially causing a crash (or at least causing a lot of garbage bytes to be printed). The fix is to make sure the buffer array contains a 0/NUL byte at the end of the valid bytes that were placed there by the _read() call.
I'm trying to develop a streaming system sending multiple images to a receiving socket, which displays them. However, for some reason I can't understand, my code gets blocked at the send function after sending about 3 images. This is a snippet of my code so far:
portno = atoi(argv[2]);
sockfd = socket(AF_INET, SOCK_STREAM, 0);
if (sockfd < 0)
error("ERROR opening socket");
server = gethostbyname(argv[1]);
if (server == NULL) {
fprintf(stderr,"ERROR, no such host\n");
exit(0);
}
bzero((char *) &serv_addr, sizeof(serv_addr));
serv_addr.sin_family = AF_INET;
bcopy((char *)server->h_addr,
(char *)&serv_addr.sin_addr.s_addr,
server->h_length);
serv_addr.sin_port = htons(portno);
if (connect(sockfd,(struct sockaddr *) &serv_addr,sizeof(serv_addr)) < 0)
error("ERROR connecting");
bzero(buffer,256);
for(int i=10;i<51;i++){
std::stringstream sstm;
sstm << filename << i << ext;
result = sstm.str();
cout << result << endl;
Mat image = imread(result, CV_LOAD_IMAGE_COLOR);
image = (image.reshape(0,1));
int imgSize = image.total()*image.elemSize();
n = send(sockfd, image.data, imgSize, 0);
}
Tried to debug it, and, as I said, it gets blocket at the last line, the send function. I wonder if there's a limit on how much information can you transmit through a socket. If I move the for sentence back before the socket creation, it works like a charm, but i'm not going to create a bizillion sockets. Any help?
The send() call will block if the TCP window size goes to zero. This is almost always a result of the other side of the connection not consuming the data from a recv() call.
It's also entirely possible that imgSize is extremely huge and it just simply takes that long for the receiver to consume the stream.
You didn't share any code from the receiver side, so it's difficult to say.
I would suggest more debug spew (print statements) showing the value of imgSize and the return value of the send call. Ditto for the recv side.
Do note - that just because you sent imgSize bytes in one send call, the remote receiver may not receiver all those bytes within a single call to recv().
I want to simply connect to a server and get a response. My program is written in c++, and you can see the code here:
if((interpreterSocket = socket(AF_INET, SOCK_STREAM, 0)) < 0)
{
return SOCKETERR;
}
fcntl(interpreterSocket, F_SETFD, FD_CLOEXEC);
setsockopt(interpreterSocket, SOL_SOCKET, SO_REUSEADDR, (char *) &flag, sizeof(flag));
setsockopt(interpreterSocket, IPPROTO_TCP, TCP_NODELAY, (char *) &flag, sizeof(flag));
setsockopt(interpreterSocket, SOL_SOCKET, SO_REUSEADDR , (char *) &flag, sizeof(flag));
address.sin_family = AF_INET;
address.sin_addr.s_addr = inet_addr(INTERPRETERADDR);
address.sin_port = htons(INTERPRETERPORT);
adlen = sizeof(address);
if((rc = connect(interpreterSocket, (struct sockaddr *) &address, adlen)) < 0)
{
close(interpreterSocket);
return SOCKETERR;
}
The problem is when I run this program sometimes it has some trouble, so I have to kill the process. After that when I run the program, the connect function does not return and the program stops at the if line. I think this problem most be related to a socket that does not close in a proper manner.
I should mention that I run this program in CentOS.
Thanks in advance.
EDIT
I had one more problem, that caused the program stop at connect() function and it was some routing problems at the server.
You are using blocking socket so connect blocks until it connects to server or timeout passes. To set sockets to non-blocking, you should use ioctlsocket function, exactly with FIONBIO command as second argument.
Remark that when you set sockets to non-blocking, you should start using select function to read or write to socket.
EDIT
Sorry, i forgot that's about Linux. It is possible to do nonblocking I/O on sockets by setting the O_NONBLOCK flag on a socket file descriptor using fcntl.
I am developing a C++ app in openSUSE 12.3 and one of it's part is responsible to send data to a device via Socket (in LAN). I am using this code
int sockfd, portno, n;
struct sockaddr_in serv_addr;
struct hostent *printer;
portno = 9100;
sockfd = socket(AF_INET, SOCK_STREAM, 0);
if(sockfd < 0) error("ERROR opening socket\n");
printer = gethostbyname("100.0.69.23");
if(printer == NULL) error("No such device on 100.0.69.23\n");
//set bit set to zero
bzero((char *) &serv_addr, sizeof(serv_addr));
serv_addr.sin_family = AF_INET;
bcopy((char *) printer->h_addr, (char *) &serv_addr.sin_addr.s_addr, printer- >h_length);
serv_addr.sin_port = htons(portno);
if(connect(sockfd, (struct sockaddr *) & serv_addr, sizeof(serv_addr)) < 0)
{error("ERROR connecting");
return;
}
n = write(sockfd, data, datalenght);
if(n < 0) error("ERROR sending command to printer");
n = read(sockfd, buffer, 200);
I think the code is correct but the connect function returns -1 and seems that could not connect to the device (printer) . This code was written in openSUSE 11 and was working OK and I could send/receive data to device but when I copy/paste it to new system (openSUSE 12.3) it gives me failure in connecting. I ping result on the specific IP which is in use show that device is reachable via LAN
I think you should consider the possibility that hostent returned by gethostbyname function might have AF_INET6 address family (in which case it will be IPv6 instead of IPv4 address).
http://linux.die.net/man/3/gethostbyname
So you can either use GNU extension function gethostbyname2 function that will allow you to specify address family.
printer = gethostbyname2("100.0.69.23", AF_INET);
Or instead you can use getaddrinfo function, as gethostbyname function is said to be obsolete, by the documentation.
As already mentioned, you are checking for printer == NULL before initializing it. I think you meant the following instead:
sockfd = socket(AF_INET, SOCK_STREAM, 0);
if (sockfd < 0) error("ERROR opening socket\n");
printer = gethostbyname("100.0.69.23");
...
Also the structure of the code seems to indicate that when you want to send a command to the printer you connect(), write() then read(), which is OK if you are only ever sending one command, but suboptimal if you are sending multiple commands. In the latter case you want to separate the connect() from the write() as it's fairly expensive to connect so you want to do it just once.
I have a connection protocol that has been defined by our customer. Data are sent between two linux computers using UDP and TCP protocols. The IP addresses and ports are fixed on startup.
We are sending messages at 200 Hz and I have been using connect to save some time on the transmissions.
My problem is that if there is a communication error, I need to tear down the connections and reinitialise.
I have a problem with one of the UDP connections as it will not rebind to the required address and returns errno 22.
The code I am using is something like:
int
doConnect(int& sock, int local_port, char *local_ip, int remote_port, char *remote_ip)
{
sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP);
struct sockaddr_in addr;
memset(&addr, 0, sizeof(sockaddr_in);
addr.sin_family = AF_INET;
addr.sin_port = htons(local_port);
inet_pton(local_ip,&addr.sin_addr.s_addr);
if (0 > bind(sock, (struct sockaddr*)&addr, sizeof(addr)))
{
printf("Bind Error errno = %d\n", errno);
return ERR_BIND;
}
memset(&addr, 0, sizeof(sockaddr_in);
addr.sin_family = AF_INET;
addr.sin_port = htons(remote_port);
inet_pton(remote_ip,&addr.sin_addr.s_addr);
if (0 > connect(sock, (struct sockaddr*)&addr, sizeof(addr)))
{
printf("Connect Error errno = %d\n", errno);
return ERR_CONNECT;
}
return ERR_OK;
}
The way that this is used is like this:
int s1(-1), s2(-1);
doConnect(s1, 31003, "172.17.21.255", 31006, "172.17.21.1");
doConnect(s2, 31001, "172.17.21.3", 31004, "172.17.21.1");
When an error occurs
close(s1);
close(s2);
doConnect(s1, 31003, "172.17.21.255", 31006, "172.17.21.1");
doConnect(s2, 31001, "172.17.21.3", 31004, "172.17.21.1");
Here the local address is 172.17.21.3 and I am connecting to 172.17.21.1. s1 listens to a broadcast message.
s1 successfully reconnects to the remote machine, but s2 fails with error 22 from the call to bind.
I have tried explicitly calling bind and connect to an AF_UNSPEC address immediately before I close the socket. This doesn't solve the problem.
Are there any options that I should be using?
Perhaps you could try:
int val = 1;
setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &val, sizeof(val));
I also suggest you double check that you're not passing the same socket to the two consecutive doConnect() calls (as errno 22 = EINVAL, which in the case of bind() appears to mean that the socket is already bound to an address).
The underlying socket layer might hold the port & IP address still open, even after your call to close. Try some of the following:
do a sleep(10) (or more) between the close and the call to doConnect again
configure the sockets using setsockopt with the SO_LINGER set to off
This actually happens more commonly with TCP connections, but I see no reason UDP can't have this problem as well.