[erlang-questions] UDP questions

[Felix Gallo]

I've used OSC pretty heavily with Erlang recently, and:

1) use wired connections where possible; wireless connections experience
significantly higher packet loss, and at least two different models of
wireless router displayed unusual behavior in which a steady train of UDP
packets would get increasingly geometrically delayed for no apparent
reason.

2) consult musician forums about wireless router brand / model / firmware
combinations that seem to work with the specific tools you want to use, if
you are going to use something like an iPad with TouchOSC or Lemur etc. as
a manual controller.

3) use OSC bundles where possible; not all languages have libraries which
are good at that particular section of the spec, but properly implemented
bundles can significantly improve sync and a feeling of snappiness in
non-musical applications, such as higher level control.

4) Limit your packet sizes to 1500 bytes or lower on a LAN.  For single
messages this is usually pretty easy unless you're trying to send data
instead of commands, which I don't recommend.  You can breach the limit if
you pack a bunch of commands into a bundle, but if your application layer
is smart, it can fill up an outgoing packet to 500 bytes or whatever, and
then save off any further messages for the next packet.  With good
switches, good PHYs (e.g. Intel), good OS with well-tuned buffers or good
defaults, you should be able to run at 100Mb line rate.  In the real world,
sometimes you don't get to pick all of those things, so having your OSC
code be tunable (or self-tunable) down in packet size and packet rate is a
good practice.

5) OSC is super awesome because there's a bunch of controllers, libraries,
real time graphical monitors, etc., for it, and it's pretty familiar in the
entertainment space, but it's also pretty verbose and hefty on the wire.
Cap'n Proto, protobufs and thrift are nearby cousins that deserve a look or
two if you're really pushing OSC out of its comfort envelope.

F.


On Wed, Jan 27, 2016 at 5:24 PM, Serge Aleynikov <serge@REDACTED>
wrote:

> In addition to what others have said, the max UDP binary size that can be
> sent/received is:
> 64k - (sizeof(IPHeader) + sizeof(UDPHeader)) = 65535- (20 + 8) = 65507.
> This is the UDP protocol's limitation.  I would say if you use UDP, the
> {packet, N} option makes little sense, since each udp message is delivered
> as a whole (UDP is message oriented vs. TCP that is byte-oriented).
>
> I see between your 3rd and 4th questions there's some confusion. UDP
> fragmentation may happen at the network layer (IP) when sending a large
> datagram (> MTU size), but it's defragmented by the network stack, and
> delivered to the transport layer (UDP) and consequently the user space as a
> whole message (preserving message boundaries).
>
> Regards,
>
> Serge
>
> On Wed, Jan 27, 2016 at 10:27 AM, Joe Armstrong <erlang@REDACTED> wrote:
>
>> Hello,
>>
>> I have a simple UDP client/server
>>
>> The server is on a fixed port 4567 - I open it like this
>>
>>     {ok, Socket} = gen_udp:open(4567, [binary]),
>>
>> then wait for registrations
>>     receive
>> {udp, Socket, _Ip, _Port, <<"register">>) ->
>>
>>
>> Clients do this:
>>
>>      {ok, Socket} = gen_udp:open(0, [binary]),
>>      gen_udp:send(Socket, "localhost", 44567, <<"register">>),
>>      ...
>>
>> I'm testing on "localhost"
>>
>> After registration the processes send binaries to each other
>>
>> This works fine for small binaries but gen_udp:send fails  with
>> {error,emsgsize} for large binaries
>>
>> So I have a few questions:
>>
>>     1) Can I find out the max binary size that can be sent/received?
>>     2) Can I increase the max size?
>>     3) Is there a guaranteed minimum packet length that will not be
>> fragemented?
>>     3) Can received packets be fragmented - TCP has a  {packet,N}
>>        option and some built-in defragmentation, what's the story for
>>        UDP?
>>
>> I think I know the answers to these but I'm not really sure - could
>> somebody
>> who really knows enlighten me?
>>
>> Thanks
>>
>> /Joe
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160127/5c14f1e5/attachment.htm>