carmen wrote:
One observation that comes out of this is that it would be nice to be able to change the listening port of a netreceive object with a message. Then I could have instantiated all 3 with a "dummy" port-number initially, and then changed them to dummy + $id, making them all unique. I suppose it's probably possible to instantiate the object with something like [netreceive $2 1], but that means that I still have hard-code the port numbers *somewhere*, and I am trying to make my objects very modular... Any thoughts on this?
you could do something like, use one netrecieve and prepend a selector at the source(s), a [route googlizer EEGhelmet tripwire] could forward them as appropriate, exchanging the need to think about hardcoded ports with a more memorable symbol.
this assumes a netrecieve can accept connections from multiple clients at once. i havent tested. but isnt that the way it works with eg HTTP or any other low-port service? theres also [netclient] and the [OSC*] family of objects..
If you're using UDP, anybody can send messages to a netreceive, with TCP you need to use netserver if you want more than one connection. It's probably more stable to make a netreceive or netserver for each possible port than to change the port on the fly, because the underlying socket interface has to be completely reinitialized when you change the port anyway. I think it's probably abusing the internet protocol to use randomly changing port numbers although FTP does this sometimes using a fixed port for control messages and a variable one for the file transfers.
Martin
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list