I’m trying to find a good-working combination of tcpserver and tcpclient for the 64 bit version of Pure Data on macos, windows and linux in order to send fudi messages between the different clients via the server.
I started with maxlib but found that tcpserver and tcpclient are not part of the distribution anymore and in the old v0-0 distribution they are partially 32 bit. I contacted Fred Jan and he directed me to the mrpeach and iemnet libraries since they are maintained and further developed.
It seems that objects from the mrpeach library give me trouble (crashing) (especially on windows) although this needs further testing on my side.
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. Tcpserver however does output the received messages as list. 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.
Best regards!
Edwin
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/
Tcpserver however does output the received messages as list.
Which one? [iemnet/tcpserver] does not, as far as I know. See above reasons.
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
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
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].
- 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.
- 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.
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.
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.
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.
Roman
[1] https://www.netpd.org/protocol [2] https://github.com/reduzent/netpd
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
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
On 3/31/20 9:01 PM, Edwin van der Heide wrote:
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.
this (that you cannot do bi-directional communication with a connectionless protocol like UDP) is a common misconception found in the computer music world (and probably in other bubbles as well, but i don't follow those closely). luckily it is not, else there DNS-system wouldn't work and the internet would have been a lot less fun.
gamdsr IOhannes
Dear Roman,
On 30 Mar 2020, at 14:32, Roman Haefeli reduzent@gmail.com wrote:
I solved the delimiting part for OSC and FUDI for netpd-server. Check the abstraction [tcpsocketserver] in:
On https://github.com/reduzent/netpd-server/ I only find the delimiting part for OSC. Do you have it also for FUDI?
Best!
Edwin
On Mon, 2020-03-30 at 21:27 +0200, Edwin van der Heide wrote:
On https://github.com/reduzent/netpd-server/ I only find the delimiting part for OSC. Do you have it also for FUDI?
Sorry, I posted the link without even checking if it's there. My memory has tricked me.
It seems to be part of mrpeach. You can get it from Deken (a.k.a "Help" -> "Find externals").
Roman
On 30 Mar 2020, at 22:39, Roman Haefeli reduzent@gmail.com wrote:
On Mon, 2020-03-30 at 21:27 +0200, Edwin van der Heide wrote:
On https://github.com/reduzent/netpd-server/ I only find the delimiting part for OSC. Do you have it also for FUDI?
Sorry, I posted the link without even checking if it's there. My memory has tricked me.
It seems to be part of mrpeach. You can get it from Deken (a.k.a "Help" -> "Find externals").
Roman
Excellent.
As I wrote to IOhannes I’ve replaced mrpeach/tcpclient with iemnet/tcpclient and parse the bytes using [list store] (including some logic around it) and the crashes are gone on all platforms.
Best!
Edwin
On Mon, Mar 30, 2020 at 3:36 AM Edwin van der Heide pd@evdh.net wrote:
It seems that objects from the mrpeach library give me trouble (crashing) (especially on windows) although this needs further testing on my side.
Which mrpeach objects are crashing on Windows? I'd like to know so I can fix it.
Martin
Dear Martin,
As I wrote I’m not 100% sure that the crash is caused my mrpeach but it seems like it. I’m not sure how to find a proper crash report on windows. Attached is a crash report of tcpclient on macos. Although on macos it happens very rarely.
Here is a link to the server patch and a stripped down version of the client patch: https://www.evdh.net/tcpserver_and_tcpclient_patches.zip
It’s the client patch that is crashing. It often crashes right away when you move a fader. Sometimes it takes a while. It seems to crash easier on a faster windows machine than on a slower one.
Best!
Edwin
On 30 Mar 2020, at 17:05, Martin Peach chakekatzil@gmail.com wrote:
On Mon, Mar 30, 2020 at 3:36 AM Edwin van der Heide pd@evdh.net wrote:
It seems that objects from the mrpeach library give me trouble (crashing) (especially on windows) although this needs further testing on my side.
Which mrpeach objects are crashing on Windows? I'd like to know so I can fix it.
Martin
On 3/30/20 9:29 AM, Edwin van der Heide wrote:
My problem is that iemnet/tcpclient outputs the the received messages as bytes in individual messages instead of a list.
actually it's the other way round: mrpeach/tcpclient outputs the received messages as lists instead of bytes.
assuming that you get full messages over a stream-based protocol will sooner or later bite you¹. so, as roman said, the behaviour of iemnet is quite intentional.
in any case, you need to solve the problem of interleaved messages from multiple clients.
On 3/30/20 2:32 PM, Roman Haefeli wrote:
Tcpserver however does output the received messages as list.
Which one? [iemnet/tcpserver] does not, as far as I know. See above reasons.
actually it can be forced to do that. but you shouldn't.
famrds IOhannes
¹ i'm tempted to ask you to consider whether your crashes might actually be related to this. but then, most likely they are not.
On 30 Mar 2020, at 22:22, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 3/30/20 9:29 AM, Edwin van der Heide wrote:
My problem is that iemnet/tcpclient outputs the the received messages as bytes in individual messages instead of a list.
actually it's the other way round: mrpeach/tcpclient outputs the received messages as lists instead of bytes.
assuming that you get full messages over a stream-based protocol will sooner or later bite you¹. so, as roman said, the behaviour of iemnet is quite intentional.
in any case, you need to solve the problem of interleaved messages from multiple clients.
Yes you are right about iemnet/tcpclient vs mrpeach/tcpclient. And yes, I understand that solving the interleaved messages is important but that happens on the server side, not on the client side.
On 3/30/20 2:32 PM, Roman Haefeli wrote:
Tcpserver however does output the received messages as list.
Which one? [iemnet/tcpserver] does not, as far as I know. See above reasons.
actually it can be forced to do that. but you shouldn't.
famrds IOhannes
¹ i'm tempted to ask you to consider whether your crashes might actually be related to this. but then, most likely they are not.
I’m now even more sure that it is mrpeach/tcpclient that crashes. I’ve replaced it with iemnet/tcpclient and parse the bytes using [list store] (including some logic around it) and the crashes are gone on all platforms.
Best!
Edwin
On 3/30/20 11:03 PM, Edwin van der Heide wrote:
in any case, you need to solve the problem of interleaved messages from multiple clients.
Yes you are right about iemnet/tcpclient vs mrpeach/tcpclient. And yes, I understand that solving the interleaved messages is important but that happens on the server side, not on the client side.
well, yes. interleaving is indeed only a problem on the server side.
but even with [mrpeach/tcpclient] you will eventually receive lists that are not delimited at the ";". e.g. two packages "floa" and "t 23;\n bang;\n" is totally possible.
I’ve replaced it with iemnet/tcpclient and parse the bytes using [list store] (including some logic around it) and the crashes are gone on all platforms.
hooray.
gfmadsr IOhannes
On 31 Mar 2020, at 09:21, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 3/30/20 11:03 PM, Edwin van der Heide wrote:
in any case, you need to solve the problem of interleaved messages from multiple clients.
Yes you are right about iemnet/tcpclient vs mrpeach/tcpclient. And yes, I understand that solving the interleaved messages is important but that happens on the server side, not on the client side.
well, yes. interleaving is indeed only a problem on the server side.
but even with [mrpeach/tcpclient] you will eventually receive lists that are not delimited at the ";". e.g. two packages "floa" and "t 23;\n bang;\n" is totally possible.
Thanks for pointing out that delimiting is also needed on the client side.
Best!
Edwin
I’ve replaced it with iemnet/tcpclient and parse the bytes using [list store] (including some logic around it) and the crashes are gone on all platforms.
hooray.
gfmadsr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi All,
I would be happy to add abstractions based on maintained objects from other libraries to the maxlib library (where I caused all this trouble by removing the instable tcp-objects).
Greetings,
Fred Jan
On 31/03/2020 21.03, Edwin van der Heide wrote:
On 31 Mar 2020, at 09:21, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 3/30/20 11:03 PM, Edwin van der Heide wrote:
in any case, you need to solve the problem of interleaved messages from multiple clients.
Yes you are right about iemnet/tcpclient vs mrpeach/tcpclient. And yes, I understand that solving the interleaved messages is important but that happens on the server side, not on the client side.
well, yes. interleaving is indeed only a problem on the server side.
but even with [mrpeach/tcpclient] you will eventually receive lists that are not delimited at the ";". e.g. two packages "floa" and "t 23;\n bang;\n" is totally possible.
Thanks for pointing out that delimiting is also needed on the client side.
Best!
Edwin
I’ve replaced it with iemnet/tcpclient and parse the bytes using [list store] (including some logic around it) and the crashes are gone on all platforms.
hooray.
gfmadsr IOhannes
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
On 31 Mar 2020, at 21:22, Fred Jan Kraan fjkraan@xs4all.nl wrote:
Hi All,
I would be happy to add abstractions based on maintained objects from other libraries to the maxlib library (where I caused all this trouble by removing the instable tcp-objects).
Greetings,
Fred Jan
Nobody caused any trouble and I have only learned. This is where it started: I discovered there is a wikipedia page for FUDI and maxlib was mentioned there: https://en.wikipedia.org/wiki/FUDI
Best!
Edwin
-
Edwin van der Heide -
Fred Jan Kraan -
IOhannes m zmölnig -
Martin Peach -
Roman Haefeli