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 reduzent@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:
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