[PD] tcpserver and tcpclient

Edwin van der Heide pd at evdh.net
Tue Mar 31 21:01:21 CEST 2020


Hi Roman,

> On 30 Mar 2020, at 23:40, Roman Haefeli <reduzent at gmail.com> wrote:
> 
> 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]. 

Yes, this is even more than I was looking for! I’m starting testing with it now. 

> 
> 
>> - 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. 

Yes, both perspectives have their own plusses and minuses.

> 
>> - 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. 

All clear.

> 
>> 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.

I would like to be sure that messages don’t get dropped. I have used UDP a lot on local networks but thought that TCP is better for internet-based use because of the guaranteed arrival.

> 
>> 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. 

I’m very curious to know whether this works indeed on the internet with only a public IP and port forwarding on the [netreceive] side. I was assuming that a (TCP) socket would be a requirement to be able to send data up and down without port forwarding on both sides but I guess I’m wrong here. I’ll do a test in the coming days to make sure this works. It would be an elegant solution for simple configurations.

> 
> 
>> 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.

Clear.

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

Thanks for all and especially netpd!

Best,

Edwin
> 
>>> 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
>> 
>> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list






More information about the Pd-list mailing list