Based on my assumptions, it may be that the OS is delaying sending the messages in case you're not finished sending them.
I think that's why Pd (and iemnet) sets the TCP_NODELAY socket option on TCP sockets .
Christof
On 15.06.2020 15:44, Martin Peach wrote:
On Sun, Jun 14, 2020 at 4:24 PM rolfm@dds.nl wrote:
(Windows 10, Pd-50.0)
i'm sending messages of 25 bytes with [mrpeach/tcpserver] to a client (NodeMCU/ESP8266),
triggered by [metro 50].
with a tcpclient in a seperate Pd the messages are received in the right order, no gaps.
Are both Pds on the same machine? (I'm guessing yes)
on the Node i get sometimes 1, most of the times multiple messages in one read.
Are they multiples of the same message or a sequence? (I'm guessing a sequence)
the sending is done with "broadcast", because in the future there will be more clients.
Does it also happen if you send only to that client? (I'm guessing yes)
how come the [mrpeach/tcpclient] and the WifiClient on the Node give different results,
and can tcpserver be 'forced' to treat them equally?
Based on my assumptions, it may be that the OS is delaying sending the messages in case you're not finished sending them. You need a break of some minimum time before the whole lot gets sent. The OS may delay longer in the case of a wireless connection to avoid network congestion. This is because TCP has no concept of packet or 'datagram' like UDP -- you can keep sending until you close the connection, so one way is to close the connection after each message. Another way would be to use a longer metro tick period so the stack times out and sends. Also try sending a longer message to force it to be sent.
Martin
any hint is welcome.
rolf
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list