[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