tags:

views:

716

answers:

3

I wanted to know how to flush the socket streams while doing socket programming in C. I tried all the options- setting TCP_NODELAY using the following code-

setsockopt(sockfd, IPPROTO_TCP, TCP_NODELAY, (char *) &flag, sizeof(int));      

Note: all the flag and sockfd are declared correctly.

I used this function both before send() and after send() but it did not make any difference.

Also someone had suggested to use shutdown() after each send() but that works only for one instance. When i use it to send some text again, it doesn't work- actually the connection gets closed after i use shutdown().

shutdown(sockfd, SHUT_WR);

Can someone help in this regard?

I wanted to added that- the server is a Java socket and the client is a C socket. The C socket implements the JVMTI interface and sends the information to the Java socket.

+1  A: 

Doing a bit of research on Google, it doesn't seem like there's a way to flush a socket stream explicitly. You can set the TCP_NODELAY and then it will turn off the TCP Nagle algorithm. This should make sure that the data gets sent immediately and not wait until it's buffer is full before sending.

Have you used wireshark or something to see what's going behind the scenes when you set TCP_NODELAY?

Tony
I haven used any of the tools to check what's happening behind the scenes. Wat i obeserved was that the data gets sent immediately to the server once the socket connection closes or the client completes execution.
sana
And even I found that there's no explicit way to flush sockets but there were few telling that they could do it by setting TCP_NODELAY or using shutdown()
sana
Without using such tools you can't know that the data was sent when the connection was closed.
nos
+1  A: 

You might want to read The ultimate SO_LINGER page, or: why is my tcp not reliable, which I think applies to your situation.

Edit:

Calling send() on a TCP socket multiple times is not that uncommon :) It's normal usage, I mean. You probably have issues on the server side, where server expects certain number of bytes and blocks waiting for it.
As far as I know JVM TI does not dictate any over-the-wire protocol, so you'll have to come up with your own. Define structure of the record the client sends and server expects, put data length in there if size varies. You might also implement some application-level acknowledgement from server back to client.

Nikolai N Fetissov
I went through the article completely. Though I wasn't able to understand most of it. I could figure out that the Author was trying to tell- use send() and then call shutdown(). But what if i need to send the data multiple times? Its not possible right once shutdown() is called?
sana
At the server side am using a Scanner instance to read the stream. So when ever the data is available on the stream the "hasNext()" method returns TRUE and it reads using "next()" method. Do we still need the size of the data sent to be known.
sana
It's better to let the other side know what to expect. The thing is that TCP transfers data in chunks (IP packets), which don't necessarily align with the data the app sends. Ask yourself - how does the server know when one piece of data from the client ends and the other begins?
Nikolai N Fetissov
Actually u were correct. I was making a mistake in the Server side when I was usin Scanner. My friend suggested me to replace it with BufferedReader. I replaced it with BufferedReader to read byte by byte. Thanks a lot for the help.
sana
A: 

socket-unix-faq says that you can't flush sockets

Alexander Farber