[nanomsg] Re: initial code repo for Go version of SP protocols
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Mon, 24 Mar 2014 07:21:59 -0700
On Mar 24, 2014, at 1:12 AM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Garrett,
>
> Agreed. Relying on IP fragmentation and going forward with a
> simplistic UDP protocol (as outlined in the RFC) seems to be the best
> idea.
>
> Still, keep in mind that IPv6 doesn't support fragmentation.
Um… yes it does. IPv6 is different than IPv4 in that it *mandates* Path MTU
discovery, which should make it unlikely that fragments will occur, and it
specifically indicates that fragmentation is never performed by routers.
(Easing the burden on intervening infrastructure.) A *host* can still
fragment, so you can issue very large IPv6 pings for example, as well as use
very large UDP datagrams. (Well, up to 64k anyway.) In this case, the
originating sender will fragment into sizes based upon the detect path MTU.
Other ways IPv6 differ for UDP: minimum guaranteed MTU is 1280 bytes (yay!),
and UDP checksumming is mandatory in v6.
- Garrett
>
> Martin
>
> On 24/03/14 06:51, Garrett D'Amore wrote:
>>
>> On Mar 23, 2014, at 10:08 PM, Martin Sustrik <sustrik@xxxxxxxxxx>
>> wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>
>>> On 24/03/14 04:57, Garrett D'Amore wrote:
>>>> It would be pretty straight forward to add UDP support. The
>>>> issue will be defining what the wire format for UDP looks like.
>>>> I have some thoughts here and if I had my druthers each SP
>>>> message would translate to a single UDP datagram. Others might
>>>> have different ideas.
>>>
>>> Yes. I would say that UDP-mapping RFC should contain a single
>>> sentence: "SP message maps directly to an UDP datagram."
>>>
>>> That obviously entails that all messages exceeding path MTU will
>>> be dropped silently.
>>
>> Mostly agreed. However….
>>
>> *IP* can perform UDP fragment reassembly. I think it supports up
>> to 64k packets, even over link layers that are substantially
>> smaller (ethernet MTUs are 1500 bytes usually).
>>
>> 64k would probably be an ultimate size limit in any case (owing to
>> IP limitations). Minus IP/UDP header overheads of course! :-)
>>
>> What is interesting is Path MTU (and Path MTU discovery in
>> particular) tends to include a flag to tell MTU to discard
>> fragments. This is intentional so that IP will reduce the MTU to
>> something that works across all intermediate links without
>> fragmentation or fragment reassembly.
>>
>> Its not clear to me that imposing such a restriction on SP is a
>> good idea. While I think it would be a pretty bad idea to build a
>> protocol that *relied* on fragment reassembly (these are slow path,
>> edge cases in IP stacks after all), there might be real reasons to
>> support an occasional large frame. That said… why wouldn’t use TCP
>> in such circumstances? :-)
>>
>>>
>>> As for a possibility of making a more complex transport on top of
>>> UDP, the primary motive, IMO, would be to allow messages to
>>> exceed PMTU. That in turn means adding identification of peers
>>> (either by using connections or by using globally unique
>>> identifiers), sequence numbering the packets, PMTU discovery,
>>> identifying message boundaries withing packets etc. If anyone is
>>> interested in this, I'll be happy to elaborate.
>>
>> IP already does all this…. it’s called fragment reassembly.
>> nanomsg should *NOT* reinvent this particular wheel IMO. If
>> someone really cares to transport large frames, they have two
>> options:
>>
>> 1. Use TCP 2. Figure out an application layer solution
>>
>> Making SP/nanomsg offer an alternative solution just seems….
>> wasteful… to me.
>>
>> - Garrett
>>
>>
>>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTL+jsAAoJENTpVjxCNN9Y2zwH/38NdVA6a33bY1b82BaMLPkM
> T9CXM3lM9AJrY4I0bOToGghk9YpGiRs0yFQXzoHx6flaFsBtTH4NEzjVAodRW2eB
> Tkpzh0W999F0J1DuKPso8+xgK4QWGKqy4ChuNl5c4RAtLk2ennnvTlQsRR0XB+A7
> byio/BGaDnvKdfFggUVpTMqlbBoSpmMQ4gusOvRwTmqVK9D+DB4s4J+zV5RLLxSq
> F3P4JeYtQlR1VGEZoNzWlMclSaCtOEhSf3iJIYYIR0Bkcl0VjCl32dOJIUqLkHwL
> wOJ7Zs2pLPnLWk1AImWF0/n7Voq8oDLI9jmI+YJDSe7GvwDXR7/3Gtd2K6YBgBg=
> =ePt3
> -----END PGP SIGNATURE-----
>
Other related posts:
