UDP problem sending byte768 bytes

["이희승 (Trustin Lee)"]

Actually, there was a bug in DatagramChannelConfig implementation.  Now
that the fix has been checked in, it should work both for NIO and OIO.
You might give OIO UDP a try because it performs better in general.

HTH,
Trustin

Neil Avery wrote:
> We are using NIO - the configuration settings you provided in an earlier 
> email failed to configure the OIO UDP buffer size
> -Neil.
> 
> 2009/6/27 "이희승 (Trustin Lee)" <trustin at gmail.com 
> <mailto:trustin at gmail.com>>
> 
>     Thanks for the feed back. It seems like your application is running
>     in a controlled network. Otherwise such a large UDP packet could be
>     truncated or discarded.
> 
>     Out of curiosity, do you use OIO UDP or NIO UDP?
> 
>     Trustin
> 
>     Neil Avery wrote:
> 
>         Oops - forgot to add my point - thats our particular use case -
>         so 768
>         is probably ok for most cases!
>         Cheers.
> 
>         2009/6/26 Neil Avery <neil at liquidlabs.co.uk
>         <mailto:neil at liquidlabs.co.uk> <mailto:neil at liquidlabs.co.uk
>         <mailto:neil at liquidlabs.co.uk>>>
> 
> 
>         We are using it (udp) to burst a search request to hundreds or
>         thousands of machines. Sending using TCP degrades as more machines
>         are added to the network - even when using our custom connection
>         pooling we still see degradation - using udp provides much better
>         performance (and we cannot use multicast). Our message size is a
>         maximum of 5K, - btw - we use netty tcp elsewhere when reliablity is
>         required.
>         Cheers Neil.
> 
>         2009/6/26 "이희승 (Trustin Lee)" <trustin at gmail.com
>         <mailto:trustin at gmail.com>
>         <mailto:trustin at gmail.com <mailto:trustin at gmail.com>>>
> 
> 
>         By the way, please let me know if you think the default (768) is
>         not sane and should be increased. I'm not really a UDP expert so
>         other people's suggestion is appreciated.
> 
>         Thanks
> 
>         이희승 (Trustin Lee) wrote:
> 
>         Hi Neil,
> 
>         It's because the default receiveBufferSizePredictor of
>         DatagramChannel
>         is FixedReceiveBufferSizePredictor(768). You can configure
>         the channel
>         to a FixedReceiveBufferSizePredictor with different payload
>         size. For
>         example:
> 
>         DatagramChannel ch = ...;
>         ch.getConfig().setReceiveBufferSizePredictor(
>         new FixedReceiveBufferSizePredictor(1024));
> 
>         or:
> 
>         ConnectionlessBootstrap b = ...;
>         b.setOption("receiveBufferSizePredictor",
>         new FixedReceiveBufferSizePredictor(1024));
> 
>         BTW, I wouldn't recommend to using
>         AdaptiveReceiveBufferSizePrediector
>         for datagrams.
> 
>         HTH,
>         Trustin
> 
>         On 2009-06-25 오전 4:49, neilson9 wrote:
> 
>         Hi,
> 
>         Im having a couple of problems sending UDP byte[]> 768K
> 
>         For example if Im passing 1024bytes the buffer.readIndex
>         does not get
>         updated. The sender only passes 768 bytes and if I
>         manually set the
>         readIndex to 768 it sends another 768 bytes on the
>         second send. I would like
>         to iterate of the byte[] and use the offsets to prevent
>         copying data etc.
> 
>         Any help appreciated.
>         Regards Neil.
> 
>         For example:
>         byte[] payload = userdata....;
> 
>         channel = (DatagramChannel) b.bind(new
>         InetSocketAddress(0));
>         ChannelBuffer buffer = dynamicBuffer(bytes.length);
>         buffer.writeBytes(bytes);
>         LOGGER.info("Sending:" + bytes.length + " sent:" +
>         buffer.readerIndex());
>         ChannelFuture channelFuture = channel.write(buffer, new
>         InetSocketAddress(uri.getHost(), port));
>         // manually setting to see if it sends the remainder
>         buffer.readerIndex(768);
> 
>         channelFuture = channel.write(buffer, new
>         InetSocketAddress(uri.getHost(), port));
>         LOGGER.info("Sending:" + buffer.readerIndex());
> 
> 
> 
> 
> 
>         ------------------------------------------------------------------------
> 
>         _______________________________________________
>         netty-users mailing list
>         netty-users at lists.jboss.org <mailto:netty-users at lists.jboss.org>
>         <mailto:netty-users at lists.jboss.org
>         <mailto:netty-users at lists.jboss.org>>
> 
>         https://lists.jboss.org/mailman/listinfo/netty-users
> 
> 
> 
>         --
>         Trustin Lee, http://gleamynode.net <http://gleamynode.net/>
> 
>         _______________________________________________
>         netty-users mailing list
>         netty-users at lists.jboss.org <mailto:netty-users at lists.jboss.org>
>         <mailto:netty-users at lists.jboss.org
>         <mailto:netty-users at lists.jboss.org>>
> 
>         https://lists.jboss.org/mailman/listinfo/netty-users
> 
> 
> 
> 
>         ------------------------------------------------------------------------
> 
>         _______________________________________________
>         netty-users mailing list
>         netty-users at lists.jboss.org <mailto:netty-users at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/netty-users
> 
> 
> 
>     -- 
>     Trustin Lee, http://gleamynode.net
> 
>     _______________________________________________
>     netty-users mailing list
>     netty-users at lists.jboss.org <mailto:netty-users at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/netty-users
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users


-- 
Trustin Lee, http://gleamynode.net