[erlang-questions] UDP questions

[Joe Armstrong]

On Thu, Jan 28, 2016 at 2:59 AM, Felix Gallo <felixgallo@REDACTED> wrote:
> 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.

I want to connect iPad/Mac/various synths together. I hadn't heard of Lemur

I just got a midi-to-osc bridge working (midi half in swift) - osc-in erlang :-)

Just need bonjour and get http://nexusosc.com/ working then I can have fun ...


>
> 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.
>

I agree - the music world has a load of very cool devices - I've been
playing with Pure Data and my head hurts

/Joe


> 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
>>
>