[PD] Netreceive + oscillating issue

[Rick Snow]

Thank you, IOhannes and Roman for explaining this issue to me.  [iemnet/udpreceive] did work for me.

Cheers,
Rick


> 
> ------------------------------
> 
> Message: 3
> Date: Wed, 24 Mar 2021 21:41:39 +0100
> From: IOhannes m zm?lnig <zmoelnig at iem.at>
> To: pd-list at lists.iem.at
> Subject: Re: [PD] Netreceive + osc issue
> Message-ID: <8548387b-517e-43f8-26bc-5867e579ef2f at iem.at>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
> 
> On 3/24/21 21:02, Rick Snow wrote:
>> Hi all,
>> 
>> I wonder if anyone can help me out with this issue.
>> 
>> I?m receiving an OSC message using [netreceive -u -b 7002] from another piece of software on the same computer.  Netreceive is producing an error in the console reading:
>> 
>> ?recv (bin): a message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datagram into was smaller than the datagram itself. (10040)?
>> 
> 
> 
> there has been discussion at [903] about enlarging the network buffer to 
> the maximum possible frame size for UDP packages.
> 
> right now that size is rather small (4096 bytes), which is usually 
> enough for real networked traffic (as most networking components will 
> impose a default maximum package size of 1500 bytes), but when the 
> computer is "networking" with itself (communicating via "localhost") 
> that limit can be easily blown.
> 
> until the corresponding PR [1122] is accepted (and there is a bit of 
> reluctance accepting it), the only viable workaround is by not sending 
> large packets (that is: instruct your sending application to not send 
> packages that exceed the 4096 byte limit)
> 
> in the meantime, add your mojo to the PR resp issue.
> 
> fgmsar
> IOhannes
> 
> 
> [903] https://github.com/pure-data/pure-data/issues/903
> [1122] https://github.com/pure-data/pure-data/pull/1122
> 
>> The OSC message does not print from the outlet on netreceive.
>> 
>> I?m running this on a PC on 0.51.4.
>> 
>> Thanks for all advice!
>> 
>> Cheers,
>> Rick
>> 
>> 
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>> 
> 
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: OpenPGP_signature
> Type: application/pgp-signature
> Size: 840 bytes
> Desc: OpenPGP digital signature
> URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20210324/926ae9ef/attachment-0001.sig>
> 
> ------------------------------
> 
> Message: 4
> Date: Wed, 24 Mar 2021 22:20:11 +0100
> From: Roman Haefeli <reduzent at gmail.com>
> To: pd-list at lists.iem.at
> Subject: Re: [PD] Netreceive + osc issue
> Message-ID: <552c1276c20ed7c07e6e6cbd304dc38e2cad9a89.camel at gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> On Wed, 2021-03-24 at 21:41 +0100, IOhannes m zm?lnig wrote:
>> On 3/24/21 21:02, Rick Snow wrote:
>>> Hi all,
>>> 
>>> I wonder if anyone can help me out with this issue.
>>> 
>>> I?m receiving an OSC message using [netreceive -u -b 7002] from
>>> another piece of software on the same computer.  Netreceive is
>>> producing an error in the console reading:
>>> 
>>> ?recv (bin): a message sent on a datagram socket was larger than
>>> the internal message buffer or some other network limit, or the
>>> buffer used to receive a datagram into was smaller than the
>>> datagram itself. (10040)?
>>> 
>> 
>> there has been discussion at [903] about enlarging the network buffer
>> to 
>> the maximum possible frame size for UDP packages.
> 
> Alternatively, you could use [udpreceive] from iemnet that doesn't have
> this limit set.
> 
>> 
>> right now that size is rather small (4096 bytes), which is usually 
>> enough for real networked traffic (as most networking components
>> will 
>> impose a default maximum package size of 1500 bytes),
> 
> Datagrams larger than the MTU are split into smaller segments fitting
> into the MTU. On the receiving end the segments are re-assembled to
> restore the original datagram (I'm not sure which but I believe this is
> done by a lower layer of the network stack). It's still not advised to
> use larger datagrams than the MTU because if any of the segments is
> lost the whole datagram is lost. 
> 
>> but when the 
>> computer is "networking" with itself (communicating via "localhost") 
>> that limit can be easily blown.
>> 
>> until the corresponding PR [1122] is accepted (and there is a bit of 
>> reluctance accepting it),
> 
> That's actually sad. I'm in favor of the maximum size supported by
> UDP. 
> Roman
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 488 bytes
> Desc: This is a digitally signed message part
> URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20210324/ee0b793d/attachment-0001.sig>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> Pd-list mailing list
> Pd-list at lists.iem.at
> to manage your subscription (including un-subscription) see
> https://lists.puredata.info/listinfo/pd-list
> 
> 
> ------------------------------
> 
> End of Pd-list Digest, Vol 192, Issue 71
> ****************************************