tags:

views:

174

answers:

5

Hi

I opened a connection a server in the following way

SOCKADDR_IN SockAddr;
SockAddr.sin_port=htons(445);
SockAddr.sin_family=AF_INET;
SockAddr.sin_addr.s_addr=*((unsigned long*)host->h_addr);

// Attempt to connect to server
if(connect(Socket,(SOCKADDR*)(&SockAddr),sizeof(SockAddr))!=0)
{
    printf("Failed to establish connection with server\r\n");
 WSACleanup();
 system("PAUSE");
 return 0;
}

Then I try to send data over the TCP connection as follows:

unsigned char completePacket[100] = something;

send(Socket, (char *) completePacket, 100, 0);

This works fine for 2 times,but the third time it seems as if the packet is not sent... Do I need to flush the sockts after each sent or reset them in some way?

Thanks

+1  A: 

As with all socket APIs, you should be examining the return value of send() (which should be the number of bytes sent), and then using diagnostic functions to see what any problem is.

anon
Also did that, and the right amount of data bytes is send. So odd that it does not appear in the nettraffic... even when I sent it more often Wireshark cannot detect it whereas it can detect the other ones
+2  A: 
send(Socket, (char *) completePacket, 100, 0);

Is fine, but you should always check the return value. send might actually send less than you tell it to(It's unlikely this is the problem when you've sent just 300 bytes though.)

You do not need to flush a socket.

Maybe the problem is on the receiver side ? Remember that TCP provides a stream, not packets or messages. One send call might need several recv calls to receive them all. And data sent by several send calls might be received in just one recv call. You have to keep track of how much data you've received.

If you want to check what data goes over the network, install a network monitor such as Wireshark.

nos
Yes, I have installed Wireshark and that is the problem that I can not see the third packet send for some weird reason...
Check the return values of send, do you get any errors ? port 445 is a windows SMB port, it'll likely close the tcp connection if you send nonsense to it.
nos
+2  A: 

If the other side is not acknowledging the packet before the next one is sent then the additional packets may be delayed due to Nagle's algorithm, specified in RFC 896. In essence, further small sends will be buffered and sent in one larger packet as soon as the outstanding data that has already been sent is acknowledged. This helps to keep the network from being flooded with lots of small packets.

mark4o
+2  A: 

When you send small amount of data frequently, the TCP/IP stack buffers data according to its flow control algorithm. This is for optimal bandwidth utilisation. This is called the Nagle's algorithm. The observations you have are most probably due to Nagle's algorithm being on ( turned on by default). But it could be something else altogether. You could make sure by a process of elimination the following way.

Put the following code after connect

int flag = 1;
int result = setsockopt(sock,            
     IPPROTO_TCP,
     TCP_NODELAY,
     (char *) &flag,
     sizeof(flag));
if (result < 0)
... handle the error ...

If you don't see any difference in your results, your problem is not due to default flow control mechanism.

Indeera
A: 

This is a similar question to this SO question.

zooropa