On Fri, Jul 23, 2021 at 11:59:26PM +0200, Christof Ressi wrote:
On 23.07.2021 23:11, Roman Haefeli wrote:
On Fri, 2021-07-23 at 21:52 +0200, Christof Ressi wrote:
When we overhauled the networking code, I noticed that the TCP and UDP functions would both read up to N bytes (where N is currently 4096) in a single recv() call. With TCP the buffer can contain several FUDI (or other) messages, but with UDP it would only contain a single packet. So UDP was effectively much more rate limited than TCP.
I think, it _does_ make sense to treat TCP and UDP differently. With TCP, you probably want to consume only as much as you can eat at the time while keeping the rest buffered for later. OTOH, it's questionable whether "surplus" UDP packets should be stored for later. Rather - I think - they should be simply discarded.
As I understand it, when Pd is idle (finishes a 64-sample block and can't yet crunch the following one), then it goes back and re-checks for network or GUI input, and keeps doing that until either there isn't anything to read or else the next block becomes runnable. So this is a simple throttling mechanism. (And it's not necessary to put this on another thread).
However, in the context of libpd thre's no concept of "idle" and so in that setup there's only one network read per block.
And yes, this can lead to delays since the Macintosh helpfully stores unread packets until the reading process gets around to realding them. I think that also only happens in the context of libpd.
I need to add some sort of poll-it-again functionality to libpd but haven't figured out what shape it should take yet.
Miller