Dear Roman and Dan,

I’m combining my reply to both of you and hope that is ok.

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

Concerning the new [netsend] and [netreceive] objects: would I be able to use 
them without the need for port forwarding for all the participants? 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.

Thanks for informing me about netpd!!! It is amazingly extensive and much more 
than I’m looking for. I’ll have a look at it and try it out.

Also there are two more comments in the mails below:

Thanks a lot!

Edwin

> On 30 Mar 2020, at 14:32, Roman Haefeli <reduz...@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@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list




_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Reply via email to