Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 5 years ago.
Improve this question
I am working on client server project where I have to search data requested by client from a file that is on the server side.
My code on client side:
printf("Enter data to search: \n");
fgets(buf,sizeof(buf),stdin);
send(s,buf, strlen(buf),0);
printf("Result of your search: ");
if(len = recv(s, buf, sizeof(buf),0)>0)
printf("\nMessage Received From Server -\n %s\n",buf);
my code on server side:
fp=fopen("courses.txt","r");
len=recv(new_s,buf,sizeof(buf),0);
char temp[256],tmp[512];
char *search;
while(fgets(tmp, 512, fp)!=NULL)
{
search= strstr(tmp, buf);
if(search)
{
send(new_s,tmp,strlen(tmp),0);
}
}
The strstr() always returns a null value therefore it never enters the if statement.
TCP is not a message protocol. If you want to send and receive messages (which your query is) you need a message protocol. Start by defining precisely how messages are bounded (at the byte level) and then write code to send and receive a message.
Also, don't ignore the return value of recv. How do you know how many bytes you received? And don't use functions like strlen and strcpy for anything but a C-style string. For convenience, you can make your send and receive message functions take and return C-style strings. But don't assume data on the wire will be a C-style string until your code makes it one.
Related
This question already has answers here:
Is there complete isolation between two sendalls in the same TCP connection?
(1 answer)
Can't receive multiple messages on server using TCP socket (Python)
(1 answer)
Python TCP Server receives single TCP packet split into multiple packets
(2 answers)
Closed 8 months ago.
I'm working on a C project that implements a TCP client-server. The sockets and the send() functions i'm using are the one defined in the libraries sys/socket.h and winsock2.h.
My problem is that when i try to send multiple strings one after the other, some messages aren't transmitted correctly, with some data (sometimes all the message) that goes missing. The following code, for example, works without a problem when i'm running server and client on the same machine, but if I try to run it with a remote server, then the third message isn't properly received.
Client Side
char message[1024];
memset(message, 0, 1024);
fill_message(message, msg1); //A function that prints something in the message string.
//It may fill less than 1024 characters.
send(clientSocket, message, 1024,0);
fill_message(message, msg2);
send(clientSocket, message, 1024,0);
fill_message(message, msg3);
send(clientSocket, message, 1024,0);
Server Side
char message[1024];
memset(message, 0, 1024);
recv(clientSocket, message, 1024,0);
print_and_do_stuff(message);
recv(clientSocket, message, 1024,0);
print_and_do_stuff(message);
recv(clientSocket, message, 1024,0);
print_and_do_stuff(message);
Note: the string message may not be exactly of length 1024.
My solution has been to make the client wait for 1 second by calling sleep(1) after each message is sent. Is this the proper way to address the issue? Or am i missing something about how send() and recv() work?
More in general: what is the "proper" way to program with sockets? Should I maybe be sending the message byte-by-byte and specifying the length as the first thing? If someone could point me toward a good tutorial/guide on what the best practices are when working with sockets, I'd be happy to read it.
Socket functions may or may not read/send the entire data in one call, which means that you have to verify the correct reception server side, and maybe create a custom protocol on top of TCP to keep track of the size you sent and received.
TCP, contrary to UDP, guarantees the integrity of data, meaning that you won't lose anything when sending, but you may need to use multiple function calls to ensure all of the data has been sent and red.
As for good tutorial and guides, as someone already said in comments, you can find loads of examples and guides about it.
Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 3 years ago.
Improve this question
The following code is simplified.I have a server with a loop:
while(1){
fd_c = accept(fd_skt, NULL, 0);
reading = read(fd_c, buffer, 1024);
writen(fd_c, send_ok, msg_length);
}
and a client with a library which contains a socket and two functions:
int fd_skt = -1;
int connection(){
fd_skt = socket(AF_UNIX, SOCK_STREAM, 0)
connect(fd_skt, (struct sockaddr *) &skt_address, sizeof(skt_address))
writen("hello");
readn();
}
int send_another_message(){
if(fd_skt < 0)
return error(ERR_SKT_NOT_READY);
writen("I am Bob");
readn();
}
If I do this in my client the server will receives two "hello":
connection();
connection();
but if i do this in my client the server will only receive "hello" and not "I am Bob":
connection();
send_another_message();
the server doesn't receive messages.
When I use send_another_message, I don't establish a new connection (because it was previously connected with previous function call).
I can post the entire code if need.
Your server reads and writes only once on the connection, then the next loop iteration calls accept again, which will either block until there is a new connection or return an error value. In either case you overwrite your file descriptor fd_c. Therefore the server is no longer able to communicate with the old connection.
Accept the connection once, and keep the file descriptor around until the connection is closed, so you can reuse it for calls to read and write.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 4 years ago.
Improve this question
I am wondering if you need to set up the server and client sockets so that they always go
send recv send recv ...
Because I am getting an issue where I send a message, and then the initial send() receives it twice.
I send the message upload foo.c
Server displays: Message received: upload foo.c
But then the server prints the actual file contents, which should have been passed to another recv() socket call (since only the first socket in the while loop has it's contents printed)
Message received: This is some text from
the file foo.c
text hello ending
So I get the feeling it's "overflowing" into the next recv iteration.
I'm guessing you use TCP? Then you have to remember that TCP is a streaming protocol, without message boundaries and without any start or end (except connection established and closed).
A single recv call may receive less or more than what was sent in a single send call.
You need to come up with a higher-level protocol which incorporates message boundaries explicitly, for example by sending the length of the data to be received. Then you have to use loops to receive the correct amount of bytes.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 6 years ago.
Improve this question
I'm running into a strange issue trying to test a simple socket program. When I call the "accept" function here, my program seems to hang... it prints out "SENPAI PLS" but never "SADDASSDA".
I was getting past this part of my code last night. For context, this is running on a large server with quite a few other students probably trying to do the same project as me, and I'm sure some of them are leaving their server programs running.
Could the service being busy or full cause accept to just never finish?
do{
printf("SENPAI PLS\n");
clientFD=accept(serverFD, (struct sockaddr *) &clientAddress, &clientAddressSize);
printf("SADDASSDA\n");
if(clientFD==-1){
sleep(1);
}
}while (clientFD==-1);
accept will not return until a connection is accepted (unless the listening socket is in nonblocking mode).
I am programming TCP server client. I sending the three string seperately using seperate send system call.
But receiving end i getting only single string that is first string which i send. remaining two string missed.
Below i given the part of my server client program.
client.c
char *info = "infolog";
char *size = "filesize";
char *end = "fileend";
send(client, info, strlen(info)+1, 0);
send(client, size, strlen(size)+1, 0);
send(client, end, strlen(end)+1, 0);
server.c
while ((read_size = recv(client, msg, sizeof(msg), 0))) {
printf("Data: %s\n", msg);
memset(msg, 0, sizeof(msg));
}
Actual output:
Data: infolog
Expected output
Data: infolog
Data: filesize
Data: fileend
Thanks.
Try printing out read_size. You probably have received all the messages already.
Due to Nagle's Algorithm, the sender probably batched up your three send() calls and sent a single packet to the server. While you can disable Nagle's algorithm, I don't think it's a good idea in this case. Your server needs to be able to handle receiving of partial data, and handle receiving more data than it expects.
You might want to look into using an upper-layer protocol for your messages, such as Google Protocol Buffers. Take a look at the techniques page, where they describe how they might do it: build up a protocol buffer, and write its length to the stream before writing the buffer itself. That way the receive side can read the length and then determine how many bytes it needs to read before it has a complete message.
TCP is not a message protocol but a byte stream protocol.
The three send-s could be recv-ed as a single input (or something else, e.g. in two or five recv etc....)
The application should analyze the input and buffer it to be able to splice it in meaningful messages.
the transmission may split or merge the messages, e.g. intermediate routers can and will split or merge the "packets".
In practice you'll better have some good conventions about your messages. Either decide that each message is e.g. newline terminated, or decide that it starts with some header giving its size.
Look at HTTP, SMTP, IMAP, SCGI or ONC/XDR (documented in RFC5531) as concrete examples. And document quite well your protocol (a minima, in long descriptive comments for some homework toy project, and more seriously, in a separate public document).