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