Re: DatagramSocket receive performance

I'll add my 2 cents about the packet loss. Without setting the receive
buffer size on the socket you probably get a default buffer of 8K. This
is pretty shallow for high data rates without flow control. If the VM
turns its back for just a second (GC) and if a burst comes from the
server the buffered packets will be overwritten (dropped) by the newly
arriving packets.

As far as the setLength() call on the reused client DatagramPacket I think
that winsock is doing some strange accounting on the socket buffer when
you pull out less data than was delivered. Even with this call though you may
see the problem again at a higher data rate and you may see it in the java
client before the native one.

Your native client code is ether quicker on the draw and never needs 8K
of data buffered locally, or it is using a deeper buffer that can withstand a
bigger delivery burst in between scheduling.

You can detect this by putting a sequence number in the payload and
watching at the client to see when they skip or go out of order.

I've had similar problems working with UDP apps that want a reliable
delivery semantic.

Hope this helps.



On Sat, 24 Mar 2007, Ron wrote:

On Mar 23, 11:30 pm, Esmond Pitt <esmond.p...@xxxxxxxxxxxxxxxxxx>
wrote:
Ron wrote:
If anyone knows, I sure would appreciate a hint. :D

When you receive into a DatagramPacket its length is reset to the length
of the incoming data if it's shorter than the original length. So if you
keep receiving variable-length datagrams into the same DGP the DGP will
keep shrinking, and you will be losing data at the end of the larger
datagrams received.

See src/{solaris,windows}/native/java/net/PlainDatagramSocketImpl.c, end
of the receive0() function.

Gah. Not sure how I missed that. Thank you.

Unfortunately I'm still confused. I totally understand how this could
result in losing data. But I was actually seeing packets go missing
entirely.

Without setLength(), the count variable in my java program would trail
the count variable in my c program. As soon as added setLength(), the
counts in the two programs matched. This was true, even if I added
setLength(0) at the start of the loop! The count would be fine, I
just could never see the contents of the packet. I think there must
be more to the story.



.

Relevant Pages

  • Re: In-tree version of new FireWire drivers available
    ... Just to recap, the dual buffer receive mode, as described in section ... quadlet aligned amount of header data can be appended into one buffer ... *either* the header buffer or the payload buffer fills up. ... enough to hold headers for all the packets it takes to fill up the ...
    (Linux-Kernel)
  • Re: Deaf CAsyncSocket on Windows Service.
    ... To read them out I need a buffer to ... Short packets at the sender are coalesced into longer packets. ... THe receiver says "I have this much buffer space" and the sender is free to send ... You get an OnReceive notification if there is input data to be read. ...
    (microsoft.public.vc.mfc)
  • Re: Cisco 7204VXR Interface ignored packet
    ... Input queue drops (ignored packets) are usually due to buffers not being ... The buffer defaults are good 98% of the ... 256 max cache size, 256 in cache ... 22496866 hits in cache, 0 misses in cache ...
    (comp.dcom.sys.cisco)
  • Re: Persistent stall in the Cypress FX2 FIFO
    ... the FX2's firmware code, would be to install some sort of stub routines ... > how long they are (it appends even for 4 byte long packets). ... > a packet from the FIFO before sending the next one all works fine... ... smaller or larger than what a single buffer could hold. ...
    (comp.arch.embedded)
  • Re: Waveform Audio - MMSYSERR_INVALPARAM
    ... Also, packets/buffers that you waveOutWrite, are packets ... right after the last sample from the previous buffer seamlessly. ... the waveOutWrite function DON'T return the error. ...
    (microsoft.public.pocketpc.developer)