thanks for all the hints,
i hope to test some more tomorrow .
rolf
Roman Haefeli schreef op 15-06-2020 17:24:
Hi Rold, Hi Martin
On Mon, 2020-06-15 at 09:44 -0400, Martin Peach wrote:
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.
That probably forces the underlying framework to create messages of the desired format. What if you want to send many messages immediately?
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.
How can you know what is a time that works (over wifi, vpn, ethernet)? That is not using the TCP protocol as intended.
Also try sending a longer message to force it to be sent.
What a horrible advice! Just stuff more unnecessary data into to pipe to force it to put delimiters at the right spot!
Seriously, what you lack is some kind of delimiting mechanism in order to be able to transmit packets through a stream-oriented protocol such as TCP or serial line. mrpeach tcp classes do a great job in obfuscating the true nature of TCP by outputting randomly assembled lists of floats instead of a stream of float (like iemnet).
OTOH, mrpeach comes with [slipenc] and [slipdec] which implement SLIP which is probably the simplest available delimiting mechanism.
This should work:
[send <your message encoded as list of bytes>( | [slipenc] | [tcpclient]
[tcpserver] | [slipdec] | [print]
I'm sure there is some implementation of SLIP for the NodeMCU somewhere.
Things would get more complicated when you receive TCP data from many clients in parallel, but you seem to want to only send to many clients.
An alternative approach would be to use UDP instead of TCP. UDP thinks already in packets, but chances are that packets are lost on the way, while TCP is absolutely reliable.
Roman
it took me some time but here's what i found out:
(i could only work with the mrpeach library on deken which is the one from extended ).
the tests were with 3 clients: NodeMCU (Wifi ESP8266), Arduino Wifi Rev2 (Wifi NINA), old macbook (Pd tcpclient).
laptop Windows 10 Pd-50.0 : [metro 20] [message of 25 bytes( - SLIPENC - broadcast - tcpserver (iemnet or mrpeach).
for the Node and the Arduino there's not a real difference between mrpeach or iemnet. both clients report getting a burst every 240msec average, so mostly 12 messages in one go.
the pd-client on the macbook reports for iemnet 63-77% messages arriving in 20msec after the one before, the rest in bursts. the scores for mrpeach were varying more, from 75% to a low of 40%. (but i did not test for days on end, so it's nothing more than an educated impression).
i guess the difference between the Pd-client and the others is due to the specific Wifi libraries.
the outcome of these tests si that tcpserver is not suitable for my installation(s).
thanks everyone for your contributions in this thread.
rolf
the outcome of these tests si that tcpserver is not suitable for my installation(s).
You might try latest iemnet: https://git.iem.at/pd/iemnet/-/jobs/17401/artifacts/download?file_type=archi...
[iemnet/tcpserver] didn't have immediate sending (TCP_NODELAY) enabled.
BTW, if you always broadcast to all clients, you can just as well use [netreceive -b]. But make sure to use Pd 0.51 which includes many networking bugfixes. Sending is not multithreaded and might block, but this is only relevant if you do audio.
Finally, if you want messages to get out as fast as possible, then TCP might be the wrong approach anyway and you might want to use UDP instead. Of course, UDP is unreliable, but for things like continous streams of data this is often not a problem.
Christof
On 23.06.2020 22:04, rolfm@dds.nl wrote:
it took me some time but here's what i found out:
(i could only work with the mrpeach library on deken which is the one from extended ).
the tests were with 3 clients: NodeMCU (Wifi ESP8266), Arduino Wifi Rev2 (Wifi NINA), old macbook (Pd tcpclient).
laptop Windows 10 Pd-50.0 : [metro 20] [message of 25 bytes( - SLIPENC - broadcast - tcpserver (iemnet or mrpeach).
for the Node and the Arduino there's not a real difference between mrpeach or iemnet. both clients report getting a burst every 240msec average, so mostly 12 messages in one go.
the pd-client on the macbook reports for iemnet 63-77% messages arriving in 20msec after the one before, the rest in bursts. the scores for mrpeach were varying more, from 75% to a low of 40%. (but i did not test for days on end, so it's nothing more than an educated impression).
i guess the difference between the Pd-client and the others is due to the specific Wifi libraries.
the outcome of these tests si that tcpserver is not suitable for my installation(s).
thanks everyone for your contributions in this thread.
rolf
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Christof Ressi -
rolfm＠dds.nl