[PD] tcpserver, flush?

[rolfm at dds.nl]

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