winsock recv incomplete message problem

[mao_03]

Hi,

I programmed an application that should receive UDP packets (size 38000) and in a first step just send it to the next PC.
The packets come fast and at first i had a problem getting the packets out as fast as they came. This seems solved though by using four sockets to send the data out.

Now it looks like the recv returns with the right size of the received message (38000) but either the data is scrambled or the buffer is incomplete...

Here is a sniplet of the receiving code.

		
recvdLen = recv(dlg->udpRecvSocket, dlg->receiveBuffer1.buffer, maxLen, 0);
if (recvdLen != 0 && recvdLen != SOCKET_ERROR) {
  dlg->logFile  << "Recv1 " << recvdLen << endl;
  dlg->logFile.flush();
  dlg->receiveBuffer1.length = recvdLen;
  AfxBeginThread(UdpSenderProcedure1,dlg);
} else if (recvdLen == SOCKET_ERROR) {
  dlg->logFile << "socket_error on receive1: " << (int)GetLastError();
} else {
  return 1;
}

Any ideas what could be wrong here?

Thanks!

[MikeAThon]

If you are sharing the receiveBuffer1 buffer amongst four different threads, then you probably lack synchronization between the threads, such that one thread is writing to the buffer (maybe the main thread) while other threads expect the buffer to be constant.

Incidentally, creating a new thread is time-consuming, and your code apparently does so for each and every new datagram that's received. A better architecture would be a thread pool, where all threads in the pool are already created, but are in a wait state until work is given to them. That way, there's no overhead lost in thread creation.

Mike

[mao_03]

Hi Mike,

i am sharing 4 buffers, each one between the main task (receiver) and 1 sender task.
I thought that the sender tasks should be fast enough to do the send while the receiver task does receive 4 messages. I will put some debugging information to it to see if the buffers are getting overwritten.

I will try the threadpool to see if that makes a difference.

Thanks for your help here.

[mao_03]

Today we stumbled over an idea that could be the reason for all the trouble.

We are using a dual port GB Ethernet card on the PCI bus.
If i read the specs correctly the PCI (v2.2) bus would actually be too slow to handle the data even if we send receive 400bps and send 400bps at the same time over the same card (yet via the different Eth Ports)...

Does any one know if this could be true, or am i just trying another useless shot?

Thanks for your ideas.

[Conrad Braam]

One assumes you have eliminated any hardware between the 2 ends which would get in the way. Tell us a little more about your application or protocol, I am sure someone will have an example where they have reached similar bandwidth, or even for those with time on their hands to replicate your problem (doubtful). One assumes you used UDP only for speed, and not to get away from the need to ever acknowledge the data. Is this a close application/system that may benefit from another media-type?

[mao_03]

The solution in the end was to buy a new DualPort Gb Ethernet card basing on PCI Express port and not on PCI.
With that done the application runs smooth and no packets are lost.

I just wonder how can a supplier sell DualPort Gb cards running on PCI if they should know that the PCI bus will prevent the full bandwith to be reached.