[PD] tcpserver, flush?

[Martin Peach]

On Mon, Jun 15, 2020 at 10:11 AM Christof Ressi <info at christofressi.com> wrote:
>
> > 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 .

Right! I have that on tcpreceive and tcpsend but didn't add it to the
tcpclient and tcpserver for some reason. I will fix that.

Martin


>
> Christof
>
> On 15.06.2020 15:44, Martin Peach wrote:
> > On Sun, Jun 14, 2020 at 4:24 PM <rolfm at 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 at lists.iem.at mailing list
> >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
> >
> >
> > _______________________________________________
> > Pd-list at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list