I have a simple c program to copy an image from the server using TCP
The problem is it always fails to work with certain images, it only receives 'x' bytes and then times out.
The program is not the problem here since i have tried with different programs(C and python using bigger recv buffers) using TCP and they still fail at 'x'th bytes.
server: vxworks
client: linux
if i try connecting from SUN client using the same code, it has no problem receiving the image. I did a bit of packet sniffing and found that my client is requesting packet 'A' which has the 'x'th byte in it. The server sends it or re-transmits it, but the client never acknowledges it and timesout eventually.
Question is why is this image specific ? and only happens on linux client?
the file written to the client is always 'x' bytes long
It looks like network issue for me. What is the size of packet? Sounds strange but could not it be MTU blackhole between server and linux?
My friend once experienced this exact same problem and it turned out to that the payload of the binary image he was transferring was triggering a bug in a filtering router along way. The route would just drop the connection when a particular byte sequence passed through. Bizarre but true.
Related
Im working with TCP Sockets in C but yet dont really understand "how far" the delivery of data is ensured.
My main problem is that in my case the server sometimes sends a message to the client and expects an answer shortly after. If the client doesnt answer in time, the server closes the connection.
When reading through the manpages of the recv() function in C, I found the MSG_PEEK Flag which lets me look/peek into the Stream without actually reading the data.
But does the server even care if I read from the stream at all?
Lets say the server "pushes" a series of messages into the stream and a Client should receive them.
As long as the Client doesnt call recv() those messages will stay in the Stream right?
I know about ACK messages being send when receiving data, but is ACK sent when i call the recv() function or is the ACK already sent when the messsage successfully reached its destination and could (emphasising could) be received by the client if it choses to call recv()?
My hope is to trick the server into thinking the message wasnt completely send yet, because the client has not called recv() yet. Therefore the Client could already evaluate the message by using the MSG_PEEK flag and ensure it always answers in time.
Of course I know the timout thing with my server depends on the implementation. My question basically is, if PEEKING lets the server think the message hasnt reached it destination yet or if the server wont even care and when ACK is sent when using recv().
I read the manpages on recv() and wiki on TCP but couldnt really figure out how recv() takes part in the process. I found some similar questions on SO but no answer to my question.
TL;DR
Does the recv() function trigger sending the ACK?
No, not on any regular OS. Possibly on an embedded platform with an inefficient network stack. But it's almost certainly the wrong problem anyway.
Your question about finessing the details of ACK delivery is a whole can of worms. It's an implemention detail, which means it is highly platform-specific. For example, you may be able to modify the delayed ACK timer on some TCP stacks, but that might be a global kernel parameter if it even exists.
However, it's all irrelevant to your actual question. There's almost no chance the server is looking at when the packet was received, because it would need it's own TCP stack to even guess that, and it still wouldn't be reliable (TCP retrans can keep backing off and retrying for minutes). The server is looking at when it sent the data, and you can't affect that.
The closest you could get is if the server uses blocking writes and is single-threaded and you fill the receive window with un-acked data. But that will probably delay the server noticing you're late rather than actually deceiving it.
Just make your processing fast enough to avoid a timeout instead of trying to lie with TCP.
Setup
I have a TCP server running on a microcontroller, and a client running on a Linux Destop.
What I'm trying to do
I am establishing a TCP connection, and then periodically sending messages with lengths varying from 18 bytes all the way up to 512 bytes, from the microcontroller (server) to the desktop (client).
The messages must be sent in one packet, so the TCP stack is configured to not split up the data in the microcontroller end.
In the Linux Desktop, I am using the TCP_NODELAY option which allows messages to be sent immediately, turning off the buffering algorithm. Good, I want this.
What the issue I'm facing is
I try to set the option SO_RCVLOWAT to 18 as well. My understanding is that when I call recv() it will return when at least 18 bytes have been received, which is the smallest messages I'll receive.
This didn't work as expected, and I don't know if it's because I'm misusing the API, or what I want to do cannot be achieved with the TCP/IP stack of the Linux Kernel.
The problem is more with the small packages, recv() won't return with small buffers.
One last Note
When running the client on another microcontroller, with the same TCP/IP setup, I can send and receive the data, how I want it, with no problems.
How can I achieve what I want to do under Linux?
It's for a real time application so I need the functionality of UDP but with the reliability of TCP. Thanks in advance!
I have a simple networking program for sending and responding to HTTP requests/responses. However, if I wanted to send a HTTP or another request via a SOCKS5 proxy, how would I go about this? I'm using C Unix sockets.
I could solve this by creating a proxy server in Linux. However, my intention is so that I can send this to a proxy server I do not own so that it can be forwarded to the destination server. I couldn't seem to find a library. I found an RFC for it which I've read https://www.rfc-editor.org/rfc/rfc1928.txt , but i'm still not 100% unsure how to format my request.
Am I supposed to send the segments for the handshakes as hex? If so, would I send a string of hex 0F3504 or \x0F \x35 \x04 or 0x0F3504? Another question is do i need to denote that header = value in the message, or does the SOCKS5 server know what header i am referring to by the position of the byte it is looking at from the message I've sent?
Any clear up would be very much appreciated
Some time ago I wrote an open source C library that may help you: https://github.com/brechtsanders/proxysocket
Maybe you can use the library. Its quite easy, just replace the connect() with stuff from the library and for the rest you can keep the rest of your code that uses the socket that is returned.
Or you can take a peek in the code to see how it's done there.
I am currently working on a file server in C.
When the client requests a file from the server, it writes to a socket. The server then writes back the data with a header on it. The client reads the header and then reads the actual data. When the client is being debugged, the server terminates the connection before the client has a chance to read the data.
To address this problem, I put in code to write a byte of 0 to the server when the client is done. The server, has a final read of the socket, looking for that byte but when the client is running under the debugger, it does not wait for the read on the server.
The socket is created with the following call on the server:
int socketId = socket(AF_INET, SOCK_STREAM, 0);
What should I do?
There are many challenges with writing client-server code. In this case you are also writing a protocol but may not realize it. Your protocol needs to be defined in a way that makes it clear what is expected from each side of the communication and the scenarios are non-trivial.
Here are some related questions:
(java) basic java socket programming problem
(c) Socket Programming Problem
(c) Socket Programming -- recv() is not receiving data correctly
What if the file contains a byte of 0?
You don't need this. Just close the socket. If the peer receives a clean close, it must have already received the entire file.
It sounds like you have no error checking in your unposted code.
We found the problem yesterday. The client was writing more bytes than the server was reading due to the fact that a variable was declared of the wrong type. Thanks for the responses.
Bob
I just implemented my first UDP server/client. The server is on localhost.
I'm sending 64kb of data from client to server, which the server is supposed to send back. Then, the client checks how many of the 64kb are still intact and they all are. Always.
What are the possible causes for this behaviour? I was expecting at least -some- dataloss.
client code: http://pastebin.com/5HLkfcqS
server code: http://pastebin.com/YrhfJAGb
PS: A newbie in network programming here, so please don't be too harsh. I couldn't find an answer for my problem.
The reason why you are not seeing any lost datagrams is that your network stack is simply not running into any trouble.
Your localhost connection can easily cope with what you provide, a localhost connection is able to process several 100 megabyte of data per second on a decent CPU.
To see dropped datagrams you should increase the probability of interference. You have several opportunities:
increase the load on the network
busy your cpu with other tasks
use a "real" network and transfer data between real machines
run your code over a dsl line
set up a virtual machine and simulate network outages (Vmware Workstation is able to do so)
And this might be an interesting read: What would cause UDP packets to be dropped when being sent to localhost?