[PD] tcpserver, flush?

[Roman Haefeli]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20200615/48133eee/attachment.sig>