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