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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
