java - "Lost" UDP packets (JBoss + DatagramSocket) -


i develop part of jboss+ejb based enterprise application. module needs process huge amount of incoming udp packets. i've done load testing , looks in case of sending packets 11ms interval fine, in case of 10ms interval packets lost. it's rather strange in opinion, done 10/11ms interval load tests comparison several times , same result (10 ms - "lost" packets, 11ms - everything's fine).

if wrong synchronization, i'd expect visible in case of 11ms tests (at least 1 packet lost, or @ least 1 wrong counter value). if not because of synchronization, maybe datagramsocket through receive packets doesn't work expected.

i found receive buffer size (so_rcvbuf) has default 57344 value (probably it's underlying io network buffers dependent). suspect, maybe when buffer goes full, new incoming udp datagrams rejected. tried set value higher, noticed if exaggerate, buffer returns default size. if it's underlying layer dependent how can find out maximum buffer size os/network card jboss level?

is possible caused receive buffer size, or maybe 57344 value big enough handle cases? have experience such issues?

there no timeout set on datagramsocket. udp datagrams contains 70 bytes of data (value without datagram header included).

[edited] have use udp because receive cisco netflow data - protocol used network devices send traffic statistics. also, have no influence on sent bytes format (e.g. cannot add counters packets , on). not expected packets processed (some datagrams may lost), i'd expect process of packets. during 10ms interval tests, 30% of packets lost.

it not possible slow processing causes issue. singleton component holds reference datagramsocket calling receive method in loop. when packet received, passed queue, , processed picked pool stateless component. "facade" singleton responsible receiving packets , passing on processing (it not wait processing complete event).

thanks in advance, piotr

udp inherently unreliable.

datagrams can thrown away @ point between sender , receiver, within receiver @ level below code. setting recv buffer larger size networking code within machine buffer more datagrams should expect datagrams lost anyway.

if recv logic takes long (i.e. longer takes new datagram arrive) you'll behind , you'll miss datagrams eventually. can make sure recv code runs fast possible, perhaps move inbound datagram queue , process 'later' or on thread move problem being 1 have queue keeps growing.

[re edit...] , what's processing queue , how locking work between producer , consumers? change code recv logic increments count , discards data , loops around , see if you're losing fewer datagrams; either way, udp unreliable, have datagrams discarded , should expect , deal it. worrying means you're focusing on wrong problem; make use of data , assume wont of , program work if network gets congested , of datagrams discarded.

in summary, that's how udp.


Comments

Popular posts from this blog

linux - Mailx and Gmail nss config dir -

c# - Is it possible to remove an existing registration from Autofac container builder? -

php - Mysql PK and FK char(36) vs int(10) -