Hi,

> I'll assume you use a direct cable or put wireshark at the receiving
> computer because sending a packet is not a problem. Having the packet
> reaching the network card of the receiving computer is a different thing
> if there is something in between.

Yes, I use a cross cable and two laptop with 1gbps ethernet cards
(CPU1=T8100@2.10GHz CPU2=T2300@1.66GHz).
I use wireshark on the udp server machine in this way:
1. Start wireshark on port 9000 (udp server is listening on it).
2. Start udp server (expected packet number is set to 1)
3. Start udp client on the client machine (start sending packets, first
packet number=1)
4. When udp server signal packet loss stop the client.
5. If packet loss is not signalled try to resize the udp server form, or
reduce time interval on the client (min=0 max speed).
5. Search inside wireshark the expected lost packet: I can see the
packet (the first 4 bytes correspond to the wireshark packet number).

If I set Interval=0 (max speed) on the client, the bitrate exceeds
100Mbps, but some packets are lost.

> It is not the messages which interfere, but GUI message processing can
> be very slow compared to network messages and while a GUI message is
> processed, no other message of the same thread can be processed.
> 
>> So I've created a worker thread that
>> manage socket in its own message loop.
> 
> That's perfect. But be sure to avoid using Synchronize or to block your
> thread while the GUI handle your messages. You really have the thread
> pumping messages as fast as possible. Just read the UDP socket and put
> the message in a queue for the GUI thread, then signal the GUI that the
> queue has a new message and let the thread pump the next message.

> Look at how your worker thread handle messages. As I said above, it has
> to be as fast as possible. Just receive the data into some kind of queue
> and signal it to the GUI thread without ever waiting for the GUI thread
> to handle the data.

> Probably not. At least you have to pass data to the GUI thread.


This is the windows procedure of the udp server thread:

procedure TUDPServer.ThreadWndProc(var aMessage:TMessage);
begin
 if aMessage.Msg=WM_UDP_LISTEN then
  begin
    fExpected:=1;
    fWS.Listen;
  end;
  if aMessage.Msg=WM_UDP_CLOSE then
  begin
    fWS.Close;
  end;
  inherited ThreadWndProc(aMessage);
end;


and this is the DataAvailable of the socket:

procedure TUDPServer.WSocketDataAvailable(Sender: TObject; Error: Word);
var
  lBuffer:array[0..1500] of AnsiChar;
  lLen:integer;
  lSrc:TSockAddrIn;
  lSrcLen:integer;
  lRx:integer;
begin
  lSrcLen:=SizeOf(lSrc);
  lLen:=fWS.ReceiveFrom(@lBuffer,SizeOf(lBuffer),lSrc,lSrcLen);
  if lLen>=0 then
  begin
    inc(pBR,lLen);
    move(lBuffer[0],lRx,4);
    if lRx<> fExpected then
      PostMessage(self.fHandle,WM_UDP_DATA,lRx,fExpected);
    fExpected:=lRx+1;
    if lLen<>fExpectedSize then
      PostMessage(self.fHandle,WM_UDP_SIZE,lLen,fExpectedSize);
  end;
end;

If the thread detects a packet loss or a packet size error (size error
never happened) it sends a message to the GUI thread (self.fHandle).
No other operation is done.

> One last note: Disable any firewall and security product to do your
> testing. Many of those security products are trapping network traffic
> and can slow down thruput and may have bugs. So in case of difficulties
> like you have, it is better to disable everything and use a bare bone
> clean computer setup. Of course later you'll turn security back on.

Yes I have no firewall.

Another thing:
I have tried using udp client/server on the same computer, and in this
case the packet loss is reached only trasmitting at the max speed
possible, but:
1. Wireshark doesn't capture packets on the same machine.
2. The cpu goes very high.
So I think that packet loss is possible in this situation. I prefere to
use two separated laptops.

My client/server project size is only 12KB, is it possible to attach it
to the mail? Someone could try it...
If you think that could be a good example in order to test network udp
performance (and it is not buggy), it could be added to the user made
section of the ics site.

Thank you,

Emanuele
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to