Packet overflow in simple client/server

[mickadoo]

I'm trying to send 15000 packets using a basic client/server and measure the delays but after so many packets sent it starts going a bit out of sync. The client always reports sending 320bytes but the server starts to recieve 140 and 180 now and again.
The server recieves using:

    char acReadBuffer[kBufferSize];
    int nReadBytes;
    do {
        nReadBytes = recv(sd, acReadBuffer, kBufferSize, 0);      
        if (nReadBytes > 0) 
        {
            cout << "Received " << nReadBytes << 
                    " bytes from client." << endl; 
 

And the client sends using:

if (send(sd, kpcEchoMessage, kEchoMessageLen, 0) != SOCKET_ERROR) 
 

when sd is the socket, the kpcEchoMessage is a message of 320bytes and kEchoMessageLen is the length in bytes of kpcEchoMessage. As well as that:
const int kBufferSize = 1024;
Is declared at the start. I don't usually post looking for help but i'm running out of time for a deadline, i've been looking at this for a fair while now and a month ago i'd never seen any c++ code before.
Thanks for any help.

[sicarie]

I'm trying to send 15000 packets using a basic client/server and measure the delays but after so many packets sent it starts going a bit out of sync. The client always reports sending 320bytes but the server starts to recieve 140 and 180 now and again.
The server recieves using:

char acReadBuffer[kBufferSize];
int nReadBytes;
do {
nReadBytes = recv(sd, acReadBuffer, kBufferSize, 0);
if (nReadBytes > 0)
{
cout << "Received " << nReadBytes <<
" bytes from client." << endl;

And the client sends using:

if (send(sd, kpcEchoMessage, kEchoMessageLen, 0) != SOCKET_ERROR)

when sd is the socket, the kpcEchoMessage is a message of 320bytes and kEchoMessageLen is the length in bytes of kpcEchoMessage. As well as that:
const int kBufferSize = 1024;
Is declared at the start. I don't usually post looking for help but i'm running out of time for a deadline, i've been looking at this for a fair while now and a month ago i'd never seen any c++ code before.
Thanks for any help.

Is this a problem with the size of the packets, or the number that are sent? If it's the number that is sent, you could structure it roughly around a TCP-esque model and have an ACK sent back after every so many packets (and not have the server send the next batch until those 4 have been acknowledged...).

[lqdeffx]

not knowing the complete story, obviously...and sometimes the case always, if you are on a deadline why just use the infamous ping. you can specify how big the packets are and how many you want to send.

[mickadoo]

Thanks for the help. I can't use ping because I have to build it myself, and I have timestamping code in it to measure delays. I don't think it's a problem with the size, they're all 320 bytes. I could probably use ACK, but the idea is that i'm simulating a phone call (I know VoIP uses UDP but i won't go into that unless i have to) and I need to keep it as quick as possible. I think the problem is that the original code sent the packet, the server recieved it and echoed it back, and the client checked if it was the same packet and then moved on. Somehow by getting rid of the sanity check it's caused a problem. It's just that after so many iterations the server starts recieving the wrong amounts and recording too many recieved packets, i.e. after one session the client sent 15000 but the server recieved 15338. I'm just guessing here but it is possible the server is recieving a packet, then somehow the buffer fills up or something and the server registers as moving onto a new packet? I don't really know what i'm talking about. Thanks for the help again.
Here's a few things that may or may not be useful
The packet message:
const char* kpcEchoMessage = "This is a message containing 320 bytes aaaaaaaaaa"
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
"bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
"1234567890abcdefghijABCDEFGHIJK1MNOPQ";

The Sending method:

// Send the string to the server
if (send(sd, kpcEchoMessage, kEchoMessageLen, 0) != SOCKET_ERROR) 
{
    return 1;
}
else 
{
    return 0;
}
 

The server packet recieve:

 
char acReadBuffer[kBufferSize];
int nReadBytes;
do {
    nReadBytes = recv(sd, acReadBuffer, kBufferSize, 0);      
    if (nReadBytes > 0) 
    {
                cout << "Received " << nReadBytes << 
                    " bytes from client." << endl; 
                }
    else cout << "Unable to open file";
 
        }
        else if (nReadBytes == SOCKET_ERROR) 
        {
            return false;
        }

[sicarie]

If you're going to use UDP, the point is that you can lose packets, they can be dropped, but the bulk of them get through - like with voice, you dont' want a word coming in 5 seconds later and interjecting to the conversation, you want that dropped, so the person either picks up on it and repeats themselves, or it was one packet (maybe a quarter of a syllable - I have no real idea how much voice is in one packet, I'm just using it as an example), and you can still understand the person.

If you need all the bytes of the packets, I would not use UDP or that type of connection model (without a check), for exactly the reason you are seeing. What is the goal of the project?

[lqdeffx]

I am still learning about sockets myself but you seem to be making some assumptions that I have learned you shouldn't. Just because you specified a packet at whatever size, does not mean that is what is being sent out. Your buffer, which you seem to understand is what your computer sends/recieve packets to/from has a limit as well. To add to that, just because you sent a packet does not mean it will be correctly received, even within a LAN its possible that packets get lost or corrupted and need to be resent. On another note, you stated that you didn't want to use UDP and that you wanted to keep it as quick as possible, well UDP, being a connectionless protocol, is much faster than TCP/IP because of the less checks and acknowledgments it does. Your code, what was given, looks to be pretty straightforward, unless I'm missing something. (*looks to sicarie to possibly simplify the matter.) ... to late!

[sicarie]

(*looks to sicarie to possibly simplify the matter.)

We're in trouble...

But lqdeffx is right, there might be something going on with the packets you're sending. Did you try downloading a packet capturing program such as Ethereal or Wireshark and grabbing the packets you're sending out?

[mickadoo]

Originally, it was to measure VoIP delays over 802.11 wireless networks but right now that's a bit out of reach, and i'm working on getting this model working. It's all a bit of a mess but still i'm gonna try to get it working. I think what you're saying is that there are packets being lost, but from looking at the results it seems that the packets are being read wrong
i.e.
The server will display
320 bytes recieved from client....
for a long time and then come up with
180 bytes recieved from client....
140 bytes recieved from client....
320 bytes revieved from client....
which looks to me like it's recieving most of them fine, but every now and then it's taking in one packets and splitting it into 2 (140+180 bytes). Even stranger (to me) is that sometimes it's like it recieves a fraction of a packet, recieves a few full packets, then goes back and gets the rest of the part-packet
i.e.
320 bytes recieved from client....
80 bytes recieved from client....
320 bytes recieved from client....
320 bytes recieved from client....
240 bytes recieved from client....
Ahh i don't know. I thought this was TCP code but what you said put me off. I really don't have a clue, the guy over the project said it was TCP but we were supposed to get rid of the sanity checking and packet reply from server, so what we have now is probably some mutant, using TCP architecture but with a UDP layout.

[sicarie]

Sometimes TCP will decide to cut up your data packet, so it's possible that the 180 size datagrams are full packets you were trying to send, but they got cut up somewhere.

I would recommend looking at the packets going across the network - checking the data payload and seeing what is in there - if your full packet is, or if it's getting cut off. Then we can rule out that aspect of TCP being the culprit.

[lqdeffx]

I agree, as if I wouldn't though come on. One thing to remember, especially when using sockets and transferring data over a medium is you can not assume anything. Meaning, do not assume that the 3rd packet you sent will be the 3rd packet recieved or the size for that mater too. If anything, I would be more concerned about the integrity of the data than how many packets it took to get from 1 node to the other. That is, if I was concerned about the data to begin with, TCP vs UDP.