UDP problem sending byte768 bytes

Neil Avery neil at liquidlabs.co.uk
Sat Jun 27 03:35:48 EDT 2009


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>

> 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
>> >>
>>
>>    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>>
>>
>>
>>        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>
>>            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>
>>        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
>
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/netty-users/attachments/20090627/66bfa0bc/attachment.html 


More information about the netty-users mailing list