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 <[email protected]> > To: [email protected] > Subject: Re: [PD] Netreceive + osc issue > Message-ID: <[email protected]> > 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 >> >> >> _______________________________________________ >> [email protected] 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 <[email protected]> > To: [email protected] > Subject: Re: [PD] Netreceive + osc issue > Message-ID: <[email protected]> > 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 > [email protected] > to manage your subscription (including un-subscription) see > https://lists.puredata.info/listinfo/pd-list > > > ------------------------------ > > End of Pd-list Digest, Vol 192, Issue 71 > **************************************** _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
