Archived

This topic is now archived and is closed to further replies.

How in the....

This topic is 5619 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

The server is sending packets of 4032 bytes and the Client is recieving packets of 4380 bytes. How on earth is the client recieving more data then is sent? Any ideas would be apriciated greatly mike.

Share this post


Link to post
Share on other sites
hehe... how did you come up with that !?

anyhow, TCP/IP or UDP or IPX or what protocoll are you using?
cya,
Phil

Visit Rarebyte!
and no!, there are NO kangaroos in Austria (I got this questions a few times over in the states )

Share this post


Link to post
Share on other sites
TCP/IP. the send function returns the number of bytes sent and the value i get is 4032 just like i would expect. i can not for the life of me figure out how the client is recieving 4380 bytes.

mike.

Share this post


Link to post
Share on other sites
Ok, I''ll try to be more helpful.

Can you post your send/receive code for us to look at?

I guess it''s possible that some other process is sending data to the same port (very possible with UDP since it could be a broadcast).

Also keep in mind that with TCP/IP, if you tell the sender to send 4096 bytes, then the receiver may not receive it all at once. You may call recv() and only get 2048 bytes, which means you have to keep calling recv() and adding to your buffer until you get the entire message. This isn''t your problem, since you''re getting more than you expect, but it''s something to keep in mind anyway.

Basically, more details would help.

Share this post


Link to post
Share on other sites
Actually, I just thought of something. If you're sending multiple packets, the receive can receive as much data as is in the network buffer, which is how it could receive more.

TCP/IP connections work as a stream. If you give the receive call a 65k buffer to read into, then it'll read as much data as it can up to 65k.

So when you receive, only give a 4032 byte buffer, and you won't receive more than that.

We really need to see both sides of the code.

[edited by - cgoat on July 26, 2002 10:12:52 AM]

Share this post


Link to post
Share on other sites
okay, here is the code:

server

  
packet.m_sDataHeader.m_iType = DATA_RELAY;
packet.m_sDataHeader.m_iState = DATA_NEW;
packet.m_sDataHeader.m_iOffset = 0;
packet.m_sDataHeader.m_iSize = sizeof( struct sRelayData );

memcpy( packet.m_pData, data, sizeof( struct sRelayData ) );
packet.m_iChkSum = MAX_SIZE;

ret = ServerTCPWrite( g_hConversation[g_hCurCon], &packet, sizeof( packet ), 0 );
Sleep( TCP_DELAY );

if( ret != MAX_PACKET_SIZE )
{
sprintf( buffer, "ret=%d\r\npacket size=%d", ret, sizeof( packet ) );
MessagePopup( "Packet Size Problem", buffer );
}


Client

  
void WaitForPacket()
{
char buffer[ MAX_PACKET_SIZE+1000 ], b[256];
int len, i, t;
new_packet data;

struct sPacketHeader header;

data = NULL;
//len = recv( g_sktConnection, buffer, MAX_PACKET_SIZE, 0 );


if( g_hConCount != 0 )
{
len = ClientTCPRead( g_hConversation[g_hCurCon], buffer, MAX_PACKET_SIZE+1000, 1000 );

if( len > 0 )
{
data = malloc( sizeof(BYTE)*len );

if( len != MAX_PACKET_SIZE )
{
sprintf( b, "invalid length = %d", len );
MessagePopup( "ERROR", b );

memcpy( &header, buffer, sizeof( header ) );
}
else
{
memcpy( data, buffer, len );
//g_Q.push( data );

Push( data );
}
}
}

//Sleep( TCP_DELAY );

}


MAX_PACKET_SIZE is defined as 4036. in the server, when the number of bytes sent is anything other than that i should get a message telling me that. when i run the server, i never get a message box, so i'm assuming that the number of bytes sent is indded 4036.

the function for the client code above is running in it's own thread. when it recieves a packet it allocates a buffer for it and pushes it onto the packet queue. packets will not always be MAX_PACKET_SIZE. the code is setup to expect that just because i'm trying to fix this problem i'm having.

i originally wrote this code at home using VC++ 7, but here at work i have to use National Instruments CVI. the tcp/ip related functions are part of the CVI package.

[edited by - mike on July 26, 2002 10:35:38 AM]

Share this post


Link to post
Share on other sites
This is your problem:


  
len = ClientTCPRead( g_hConversation[g_hCurCon], buffer, MAX_PACKET_SIZE+1000, 1000 );


What you''re telling it, is basically to go ahead and receive any amount of bytes up to 5036. So what happens is your server is sending several 4036 byte packets. By the time the receiver gets around to checking for data, an entire first packet, and part of the next packet has arrived. Since you tell the receive call to go ahead and read up to 5036 bytes, it goes ahead and does just that. This is totally normal behavior. There''s 4380 bytes available, so it gets them all. This could just as easily happen the other way, where a whole packet hasn''t arrived yet, so it only gives you 3000 bytes or so.

What you have to do is set up a buffer, then read into that buffer, adding to the end until you get more than the number of bytes you want, in this case 4036. Once you have more than 4036 bytes, you take off the first 4036 bytes and convert that to your structure (memcpy to the struct address works fine). After that, you then move the remaining data in the buffer to the beginning of the buffer, and resume reading data into the buffer after that point.

Share this post


Link to post
Share on other sites
alright, thanks for the help. i had read somewhere that TCP/IP protocal kept the messages seperate. one tutorial i read stated that if your packets were X amount of bytes, then the recv function would only read X amount of bytes even if there were more than two packets waiting and even if you had told the recv function to read up to X+N bytes. clearly that is not right. i added the buffer as suggested and it seem to be working now.

thanks again for the help,
mike.

it's always good when you get things working in time for lunch...

[edited by - mike on July 26, 2002 12:08:50 PM]

Share this post


Link to post
Share on other sites
Maybe they got confused with UDP, which keeps the packets together and doesn''t return more than one packet in a receive. The disadvantage to UDP is that packets can come out of order or not at all. Theres no handshaking.

Share this post


Link to post
Share on other sites