[PD] tcpserver and tcpclient

[Roman Haefeli]

Hey

On Mon, 2020-03-30 at 20:16 +0200, Edwin van der Heide wrote:

> Here is more context:
> - What I’m interested in is to create a small and 'super simple'
> internet ensemble in which multiple participants are playing together
> over the internet. They play together, not by sending each other
> audio, but by sending their actions (control information) to each
> other. Each of the participants is not only generating its own sound
> but also the sound for the other participants locally. The reason to
> realize this with [tcpserver] in combination with [tcpclient] is that
> this way only the server needs to have a specific port open to the
> internet and the others don’t. 


Not that I want to keep you from cooking your own, but this sounds a
lot like the core (the messaging part) of of netpd[1]. However, the
protocol used there is OSC, not FUDI. If you are interested only in the
messaging aspect, have a look at [netpd-client] of the client[2]. 

 
> - My patch on the serverside is currently turning everything it
> receives into a broadcast but first includes the socket number of the
> sender in the FUDI message. This way the receiver can filter out  and
> ignore the packages it has sent itself. I have seen that
> iemnet/tcpserver has a functionality to do a broadcast with a
> specific socket excluded. By using this dynamically I could realize
> this functionality in another way.

Depending on what you do, you might even want the sending client to use
the message sent back from the server (as opposed the direct one). On
one hand, this ensure the same order of messages for all clients. On
the other hand, the sending client "feels" the same latency-induced lag
like the other clients. 

> - I have experimented with both [tcpserver] and [tcpsocketserver]
> from the mrpeach library but didn’t notice any difference (in the
> crashing behavior) on the windows side.

[tcpsocketserver] is just an abstraction, a wrapper that deals with
delimiting. 

>  As I mentioned before I’m not sure what causes the crash and it
> might be unrelated to the mrpeach library. I still have to dive into
> this deeper.
> - I have no particular reason to use FUDI and can also switch to OSC.

I didn't mean to imply OSC is more suited for this (I hope). However, I
was thinking loud that UDP might be much simpler (no need for
delimiting). But probably you have your reasons to use TCP. At least,
with netpd, I do.

> Concerning the new [netsend] and [netreceive] objects: would I be
> able to use them without the need for port forwarding for all the
> participants?

At least in 0.50.2, it seems [netreceive] has a 'send' method for
sending messages back to connected clients. From what I understand, you
can only send to all connected clients. There is also the -f flag that
creates an additional outlet that reports IP address and port number of
the sending clients. You stated above, you are actually only interested
in broadcasting, so there you go: [netreceive] and [netsend] do FUDI
over TCP and only [netreceive] needs a public IP.  


>  In any case (also besides the current project) I’m interested to
> test them. My primary platform is macos. So far I haven’t compiled
> Pure Data on the mac yet myself. 

You don't need to, unless you want the newest features of [netsend] and
[netreive]. I see that the -f flag and IPv6 support will be part of the
upcoming release.

Roman


[1] https://www.netpd.org/protocol
[2] https://github.com/reduzent/netpd

> > On 30 Mar 2020, at 14:32, Roman Haefeli <reduzent at gmail.com> wrote:
> > 
> > On Mon, 2020-03-30 at 09:29 +0200, Edwin van der Heide wrote:
> > 
> > > As a strategy I would like to compare them to tcpserver and
> > > tcpclient
> > > in iemnet. My problem is that iemnet/tcpclient outputs the the
> > > received messages as bytes in individual messages instead of a
> > > list. 
> > 
> > Yeah. TCP is a stream-oriented protocol. If you want to send
> > messages
> > through a serial line (such as TCP), you need some mechanism to
> > delimit
> > packets. With FUDI, you can use the semi-colon character as
> > delimiter.
> > However, things are a bit more complicated on the [tcpserver] side,
> > since you may receive parts of messages of different clients
> > intermittently. So, for each client you need to create a buffer
> > that
> > holds incomplete messages until enough data for a complete message
> > is
> > received.
> > 
> > I solved the delimiting part for OSC and FUDI for netpd-server.
> > Check
> > the abstraction [tcpsocketserver] in:
> > 
> > https://github.com/reduzent/netpd-server/
> 
> This is very very helpful. I’m assuming it is a further developed
> version from the one in the mrpeach library.
> 
> > 
> > 
> > > Tcpserver however does output the received messages as list.
> > 
> > Which one? [iemnet/tcpserver] does not, as far as I know. See above
> > reasons.
> 
> That is correct. I was speaking about the one from the mrpeach
> library.
> 
> > 
> > > I would like to further process the output of tcpclient with
> > > fudiparse and am looking for a good way to do this that is also
> > > light
> > > on the cpu.
> > 
> > Have you looked at [netsend] and [netreceive] from Pd? If you can,
> > check the not yet released Pd versions, since some effort has been
> > put
> > into those objects, as Dan already mentioned. They speak FUDI
> > natively,
> > no need to think about delimiting and stuff.
> > 
> > Also, is there a specific reason you need TCP and not UDP? Since
> > UDP is
> > packet oriented, you don't need any delimiting there either. 
> > 
> > Roman
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Pd-list at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> 
> > https://lists.puredata.info/listinfo/pd-list
> 
> 
-------------- 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/20200330/a409aa9c/attachment.sig>