Re: DatagramSocket receive performance

On Mar 14, 6:01 pm, "Daniel Pitts" <googlegrou...@xxxxxxxxxxxxx>
wrote:

Is the java program multithreaded? That may make a difference.

The java test program is multithreaded. I reused the tool code for
the test program, stripping out all the functionality except the part
of the swing gui that prompts the user for the IP address. After the
user enters the address, the program creates a thread with normal
priority to handle reading from the datagram socket.

Today I plan to try again but with a more simple test program that
does not use any swing, and just uses the main thread.

UDP is not a reliable protocol by definition, if you need to make sure
that all data sent gets received, you'd be better off using TCP, as
its designed to handle this.

The fact that UDP is not reliable has to do with delivery of the
packets. That means that the packets can be discarded and not
retransmitted by the source. I don't have that problem - the packets
are being delivered to my test platform just fine.

I don't think TCP would help in this situation, but I could be wrong.
Can you provide a technical explanation for why the Socket
implementation would outperform the DatagramSocket implementation in
this situation?

.

Relevant Pages

  • Re: Udp sending performance in Gbit Ethernet
    ... Not sure whether your test program or setup is correct. ... implementations of TTCP are available for Windows, ... This seems to be connected to the NIC interrupts in some way, ... > it seems like that 1024-byte packets can be sent at full rate, ...
    (microsoft.public.development.device.drivers)
  • Re: Modifying cpu registers while in turbo pascal interrupt routine ?
    ... The test program calls: 'reset interface' function. ... (it does not clear multicast ... If a send a packet of ethernet/ip/udp and data 395... ...
    (alt.comp.lang.borland-delphi)
Loading