|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 | Next > |
|
|
Re: NetAddrPerhaps the NetAddr help should be updated as this does seem to be a
perennial confusion. Or a new overview file? S. On 6 Mar 2008, at 00:41, nescivi wrote: > On Wednesday 05 March 2008 19:34:08 nonprivate wrote: >> hi marije (sorry the j got lost last time) thanks again, >> so the port in the OSCresponder argument is to specify the port >> that the >> message is being sent from (ie port XXXX in your example) is that >> correct? > > yes. > > >> >> (i don't mean to drive you crazy, replying is optional...) >> >> nescivi wrote: >>> Hiho, >>> >>> On Wednesday 05 March 2008 12:23:57 nonprivate wrote: >>>> hi marie, thanks for the reply! >>>> i'm obviously getting confused, because i thought sc could only >>>> listen >>>> to things coming in from 57120? which is what i thought you and >>>> till >>>> said before. >>>> and if i use the monome or akaRemote, and set them to send to a >>>> port >>>> number that isn't 57120, sc doesn't get anything. max/msp picks up >>>> everything though. >>> >>> it seems to be a difficult concept. >>> >>> app A sends a message out *from* port XXXX >>> *to* port 57120, on which SuperCollider listens. >>> >>> so >>> appA -> port XXXX -> port 57120 -> SClang >>> >>> upon startup SC picks a port to listen to, normally 57120, if >>> that isn't >>> available, it takes the next one, and so on. The current can >>> always be >>> checked by NetAddr.langPort >>> >>> To send a UDP message, an application needs to open up a port, >>> kick the >>> message out of that port, in the direction of the port the >>> message needs >>> to go to, on that port another application may or may not be >>> listening. >>> >>> sincerely, >>> Marije >>> >>>> nescivi wrote: >>>>> Hiho, >>>>> >>>>> On Wednesday 05 March 2008 10:51:40 nonprivate wrote: >>>>>> thanks till, it does help to know that! >>>>>> in that case, it doesn't really make sense to specify a port for >>>>>> OSCresponder to listen to, does it (?) >>>>> >>>>> yes, it does. >>>>> It determines to listen for messages coming *from* a specific >>>>> port. >>> >>> _______________________________________________ >>> sc-users mailing list >>> sc-users@... >>> http://lists.create.ucsb.edu/mailman/listinfo/sc-users > > > _______________________________________________ > sc-users mailing list > sc-users@... > http://lists.create.ucsb.edu/mailman/listinfo/sc-users _______________________________________________ sc-users mailing list sc-users@... http://lists.create.ucsb.edu/mailman/listinfo/sc-users |
|
|
Re: NetAddrhi all, sorry to chime in.
for those who don't know me, i am one of those Pd freaks... William Brent wrote: > > why don't you just _use_ nil as the NetAddr in the responder? > > Yep, it makes sense. That's what I have done in the past. On top of > the security ambiguities you mentioned (which make it not so worthwhile > to use a specific port with Pd), it would also be irritating to have to > check which port Pd happens to be using each time I run it, because it's > not consistent from one instance to the next (though, once launched, it > sticks with the same port). i just wanted to say, that this is _perfectly normal_ behaviour of any client application in the wide internet. each time i access a website with my browser, the browser will choose an _arbitrary_ port to send from and will send to port:80 (http). no browser i heard of will ever send _from_ port 80. i don't think anyone should go and try to re-define how internet connection ought to work. i only know of 2 applications that care for the sender-port: SC3 and firewalls. i am not sure whether it is so good to build firewall functionality into an audio application, but i don't want to start a flame war. > Everything is clear now. And I think it raises a good issue for Pd and > Max users. From what I'm understanding, specifying everything in detail > like this is maximally secure and reliable. afair, it is an added security to _not_ be able to pre-determine the sending port (man-in-the-middle attack); but i might be mistaken here (i couldn't find anything now) > Maybe sendOSC and udpsend > should be updated... the only thing i could imagine that might be "fixed" is to set the source-port to "0" indicating that this is a uni-directional connection. even if it does not, my understanding of RFC768 does not require that a sender has to _listen_ at the source-port for feedback ("Source Port is an optional field, when meaningful, it indicates the port of the sending process, and may be assumed to be the port to which a reply should be addressed in the absence of any other information.") finally, OSC does not say anything about the underlying protocol. especially it does not mention bi-directional communication. i guess one should not rely on a "custom to send reply messages" if one wants to communicate with other applications. sorry for the noise fgmasdr IOhannes PS: in Pd, beware of [sendOSC], it is really broken. _______________________________________________ sc-users mailing list sc-users@... http://lists.create.ucsb.edu/mailman/listinfo/sc-users |
|
|
Re: NetAddrHi IO
Your message isn't noise, I believe you're right. (By the way I almost didn't see your P.S. ;) Most client/server-based TCP/UDP stuff uses a fixed port on the server and an ephemeral port on the client, and that's as designed. I suspect this implies that SC's NetAddr should really allow for a wildcard source port, as someone else mentioned; but I haven't looked much at NetAddr and friends, so I'm not sure exactly what changes that would require. Dan 2008/3/6, IOhannes m zmoelnig <zmoelnig@...>: > hi all, sorry to chime in. > > for those who don't know me, i am one of those Pd freaks... > > > William Brent wrote: > > > why don't you just _use_ nil as the NetAddr in the responder? > > > > Yep, it makes sense. That's what I have done in the past. On top of > > the security ambiguities you mentioned (which make it not so worthwhile > > to use a specific port with Pd), it would also be irritating to have to > > check which port Pd happens to be using each time I run it, because it's > > not consistent from one instance to the next (though, once launched, it > > sticks with the same port). > > > i just wanted to say, that this is _perfectly normal_ behaviour of any > client application in the wide internet. > > each time i access a website with my browser, the browser will choose an > _arbitrary_ port to send from and will send to port:80 (http). > no browser i heard of will ever send _from_ port 80. > > i don't think anyone should go and try to re-define how internet > connection ought to work. > > i only know of 2 applications that care for the sender-port: SC3 and > firewalls. > > i am not sure whether it is so good to build firewall functionality into > an audio application, but i don't want to start a flame war. > > > > > Everything is clear now. And I think it raises a good issue for Pd and > > Max users. From what I'm understanding, specifying everything in detail > > like this is maximally secure and reliable. > > > afair, it is an added security to _not_ be able to pre-determine the > sending port (man-in-the-middle attack); but i might be mistaken here (i > couldn't find anything now) > > > > > Maybe sendOSC and udpsend > > should be updated... > > > the only thing i could imagine that might be "fixed" is to set the > source-port to "0" indicating that this is a uni-directional connection. > even if it does not, my understanding of RFC768 does not require that a > sender has to _listen_ at the source-port for feedback ("Source Port is > an optional field, when meaningful, it indicates the port of the sending > process, and may be assumed to be the port to which a reply should > be addressed in the absence of any other information.") > > finally, OSC does not say anything about the underlying protocol. > especially it does not mention bi-directional communication. > i guess one should not rely on a "custom to send reply messages" if one > wants to communicate with other applications. > > > sorry for the noise > > fgmasdr > > IOhannes > > > PS: in Pd, beware of [sendOSC], it is really broken. > > > _______________________________________________ > sc-users mailing list > sc-users@... > http://lists.create.ucsb.edu/mailman/listinfo/sc-users > -- http://www.mcld.co.uk _______________________________________________ sc-users mailing list sc-users@... http://lists.create.ucsb.edu/mailman/listinfo/sc-users |
|
|
Re: NetAddrOn 6 Mar 2008, at 13:57, Dan Stowell wrote:
The solution has always been to use nil instead of a specific NetAddr and it then accepts all sending ports. _______________________________________________ sc-users mailing list sc-users@... http://lists.create.ucsb.edu/mailman/listinfo/sc-users |
|
|
Re: NetAddr2008/3/6, thor <th.list@...>:
> > > On 6 Mar 2008, at 13:57, Dan Stowell wrote: > > > I suspect this implies that SC's NetAddr should really allow for a > > wildcard source port, as someone else mentioned; but I haven't looked > > much at NetAddr and friends, so I'm not sure exactly what changes that > > would require. > > Is there a need for a change? > The solution has always been to use nil instead of a specific NetAddr and > it then accepts all sending ports. The difference is that with "nil" you also accept all IPs. How much of a difference this makes in practice, I'm not sure, but it would presumably prevent you from (e.g.) only listening to 127.0.0.1 (localhost)? Which is a shame securitywise. Dan _______________________________________________ sc-users mailing list sc-users@... http://lists.create.ucsb.edu/mailman/listinfo/sc-users |
|
|
Re: NetAddrhi IOhannes,
On 06.03.2008, at 13:43, IOhannes m zmoelnig wrote: > for those who don't know me, i am one of those Pd freaks... welcome to the bright side of life ;) > William Brent wrote: >>> why don't you just _use_ nil as the NetAddr in the responder? >> >> Yep, it makes sense. That's what I have done in the past. On top of >> the security ambiguities you mentioned (which make it not so >> worthwhile >> to use a specific port with Pd), it would also be irritating to >> have to >> check which port Pd happens to be using each time I run it, >> because it's >> not consistent from one instance to the next (though, once >> launched, it >> sticks with the same port). > > i just wanted to say, that this is _perfectly normal_ behaviour of any > client application in the wide internet. > > each time i access a website with my browser, the browser will > choose an > _arbitrary_ port to send from and will send to port:80 (http). > no browser i heard of will ever send _from_ port 80. and it doesn't matter because TCP is connection-oriented; the server doesn't need to know the sender's address to deliver information back to the client. > i don't think anyone should go and try to re-define how internet > connection ought to work. > > i only know of 2 applications that care for the sender-port: SC3 and > firewalls. > > i am not sure whether it is so good to build firewall functionality > into > an audio application, but i don't want to start a flame war. the sender address discrimination scheme in OSCresponder has nothing to do with security concerns. just specify a nil address when registering and you will get messages from any client delivered to the corresponding responder. since UDP is connectionless, though, there are scenarios that require message dispatch based on the sender's identity. >> Maybe sendOSC and udpsend >> should be updated... > > the only thing i could imagine that might be "fixed" is to set the > source-port to "0" indicating that this is a uni-directional > connection. > even if it does not, my understanding of RFC768 does not require > that a > sender has to _listen_ at the source-port for feedback ("Source > Port is > an optional field, when meaningful, it indicates the port of the > sending > process, and may be assumed to be the port to which a reply > should > be addressed in the absence of any other information.") as soon as bidirectional communication is involved with UDP (scsynth is just one example), it makes a lot of sense to use the same port for receiving and sending, because then one less bit of information needs to be exchanged (the sender's address), as stated in the RFC. it would be great if the pd implementation could be updated to optionally allow using the same socket for sending and receiving. > finally, OSC does not say anything about the underlying protocol. > especially it does not mention bi-directional communication. > i guess one should not rely on a "custom to send reply messages" if > one > wants to communicate with other applications. OSC only defines a message exchange format, but a particular application level protocol built on top of OSC might require bidirectional communication to communicate state changes. <sk> _______________________________________________ sc-users mailing list sc-users@... http://lists.create.ucsb.edu/mailman/listinfo/sc-users |
|
|
Re: NetAddr> Perhaps the NetAddr help should be updated as this does seem to be a > perennial confusion. Or a new overview file? How about the attached one? sincerely, Marije OSC_communication
OSC communication between programs is often done to send messages from one application to another, possibly with the applications running on different computers. In SuperCollider this communication is done by creating a NetAddr of the target application and creating an OSCresponder to listen to another application. The underlying protocol of OSC is either UDP or TCP. To establish communication to another application, you need to know on which port that application is listening. For example if an application is listening on port 7771, we can create a NetAddr and send it a message: b = NetAddr.new("127.0.0.1", 7771); // create the NetAddr b.sendMsg("/hello", "there");// send the application the message "hello" with the parameter "there" To listen to another application, that application needs to send SuperCollider a message to the port SuperCollider is listening on, normally this is 57120, but it can change. The current port can be retrieved with NetAddr.langPort; // retrieve the current port SC is listening to Or you can retrieve both the IP and the port with: NetAddr.localAddr; // retrieve the current IP and port To listen to incoming message an OSCresponder needs to be created in SuperCollider. If the sending application has a fixed port it sends message from, you can set the OSCresponder to listen only to messages coming from that IP and port: n = NetAddr.new("127.0.0.1", 7771); // create the NetAddr o = OSCresponder.new(n, "/goodbye", { arg time, resp, msg; [time,resp].postln; } ).add; // create the OSCresponder o.remove; // remove the OSCresponder when you are done. Some applications (notably Pd and Max) do not send messages from a fixed port, but instead use a different port each time they send out a message. In that case the OSCresponder needs to be set up, so that it listens to messages coming from anywhere: o = OSCresponder.new(nil, "/goodbye", { arg time, resp, msg; [time,resp].postln; } ).add; // create the OSCresponder o.remove; // remove the OSCresponder when you are done. _______________________________________________ sc-users mailing list sc-users@... http://lists.create.ucsb.edu/mailman/listinfo/sc-users |
|
|
Re: NetAddrVery useful. Still not able to work on Helper for Linuxers, but at least I can use it. In attachment a "formatting template - compliant" version (Help.makeHelp("OSC_communication")). Best -a- OSC_communication OSC communication between programs is often done to send messages from one application to another, possibly with the applications running on different computers. In SuperCollider this communication is done by creating a NetAddr of the target application and creating an OSCresponder to listen to another application. The underlying protocol of OSC is either UDP or TCP. Setting up an OSC connection To establish communication to another application, you need to know on which port that application is listening. For example if an application is listening on port 7771, we can create a NetAddr and send it a message: b = NetAddr.new("127.0.0.1", 7771); // create the NetAddr b.sendMsg("/hello", "there");// send the application the message "hello" with the parameter "there" To listen to another application, that application needs to send SuperCollider a message to the port SuperCollider is listening on, normally this is 57120, but it can change. The current port can be retrieved with
NetAddr.langPort; // retrieve the current port SC is listening to b.cleanUp; Or you can retrieve both the IP and the port with: NetAddr.localAddr; // retrieve the current IP and port To listen to incoming message an OSCresponder needs to be created in SuperCollider. If the sending application has a fixed port it sends message from, you can set the OSCresponder to listen only to messages coming from that IP and port: n = NetAddr.new("127.0.0.1", 7771); // create the NetAddr o = OSCresponder.new(n, "/goodbye", { arg time, resp, msg; [time,resp].postln; } ).add; // create the OSCresponder o.remove; // remove the OSCresponder when you are done. Connecting to applications sending from a variable port Some applications (notably Pd and Max) do not send messages from a fixed port, but instead use a different port each time they send out a message. In that case the OSCresponder needs to be set up, so that it listens to messages coming from anywhere: o = OSCresponder.new(nil, "/goodbye", { arg time, resp, msg; [time,resp].postln; } ).add; // create the OSCresponder o.remove; // remove the OSCresponder when you are done. On 7 Mar 2008, at 00:44, nescivi wrote:
-------------------------------------------------- Andrea Valle -------------------------------------------------- CIRMA - DAMS Università degli Studi di Torino --> andrea.valle@... -------------------------------------------------- " Think of it as seasoning . noise [salt] is boring . F(blah) [food without salt] can be boring . F(noise, blah) can be really tasty " (Ken Perlin on noise) _______________________________________________ sc-users mailing list sc-users@... http://lists.create.ucsb.edu/mailman/listinfo/sc-users |
|
|
Re: NetAddrHiho,
On Thursday 06 March 2008 19:02:48 Andrea Valle wrote: > Hi Marije, > > Very useful. Still not able to work on Helper for Linuxers, but at > least I can use it. > In attachment a "formatting template - compliant" version > (Help.makeHelp("OSC_communication")). I did start out from a file created by Helper, but as soon as I got to editing it in Amaya (not really succesfull), and then Quanta (at least that didn't do weird stuff), some of it gets lost.. I notice one "b.cleanup" line in your version that is out of place. Sincerely, Marije > > Best > > -a- >  > > On 7 Mar 2008, at 00:44, nescivi wrote: > > On Thursday 06 March 2008 03:50:47 Scott Wilson wrote: > >> Perhaps the NetAddr help should be updated as this does seem to be a > >> perennial confusion. Or a new overview file? > > > > How about the attached one? > > > > sincerely, > > Marije<OSC_communication.html>________________________________________ > > _______ > > sc-users mailing list > > sc-users@... > > http://lists.create.ucsb.edu/mailman/listinfo/sc-users > > -------------------------------------------------- > Andrea Valle > -------------------------------------------------- > CIRMA - DAMS > Università degli Studi di Torino > --> http://www.cirma.unito.it/andrea/ > --> http://www.myspace.com/andreavalle > --> andrea.valle@... > -------------------------------------------------- > > > " > Think of it as seasoning > . noise [salt] is boring > . F(blah) [food without salt] can be boring > . F(noise, blah) can be really tasty > " > (Ken Perlin on noise) _______________________________________________ sc-users mailing list sc-users@... http://lists.create.ucsb.edu/mailman/listinfo/sc-users |
|
|
Re: NetAddrGreat Marije, this file will really be helpful for people.
One note: >Some applications (notably Pd and Max) do not send messages from a fixed port, but >instead use a different port each time they send out a message. Not sure if I was clear when I reported back about this, but it seems like once Pd and Max are set up to start sending OSC, the same port is used for each message transmission. It's only upon disconnecting/reconnecting, or quitting the application and starting it up again that the port changes. A tiny point, I know, but thought I'd throw it in there while the ink was still wet... On Thu, Mar 6, 2008 at 4:06 PM, nescivi <nescivi@...> wrote: Hiho, -- William Brent "Great minds flock together" Conflations: conversational idiom for the 21st century www.conflations.com _______________________________________________ sc-users mailing list sc-users@... http://lists.create.ucsb.edu/mailman/listinfo/sc-users |
|
|
Re: NetAddr
Yes, the fact is that the html is mac biased for historical reason.
I had tried to generalize over the templates but we should have a really cleaner html with a css. -a- On 7 Mar 2008, at 01:06, nescivi wrote:
-------------------------------------------------- Andrea Valle -------------------------------------------------- CIRMA - DAMS Università degli Studi di Torino --> andrea.valle@... -------------------------------------------------- " Think of it as seasoning . noise [salt] is boring . F(blah) [food without salt] can be boring . F(noise, blah) can be really tasty " (Ken Perlin on noise) _______________________________________________ sc-users mailing list sc-users@... http://lists.create.ucsb.edu/mailman/listinfo/sc-users |
|
|
Re: NetAddrQuoting stefan kersten <sk@...>:
> hi IOhannes, > > On 06.03.2008, at 13:43, IOhannes m zmoelnig wrote: >> for those who don't know me, i am one of those Pd freaks... > > welcome to the bright side of life ;) i should say something really clever here, how light and bright and night Pd really is. i leave this as an exercise to the reader. >> >> each time i access a website with my browser, the browser will >> choose an >> _arbitrary_ port to send from and will send to port:80 (http). >> no browser i heard of will ever send _from_ port 80. > > and it doesn't matter because TCP is connection-oriented; the server > doesn't need to know the sender's address to deliver information back > to the client. while you are right and my example was probably a not so strong one, i still stand by what i say. > > the sender address discrimination scheme in OSCresponder has nothing > to do with security concerns. i used "security" mainly because it was already part of the discussion. > > as soon as bidirectional communication is involved with UDP (scsynth > is just one example), it makes a lot of sense to use the same port > for receiving and sending, because then one less bit of information > needs to be exchanged (the sender's address), as stated in the RFC. the RFC states that the sender port can be submitted in the UDP-header, and that this port "may be assumed to be the port to which a reply should be addressed". i would say that this makes it clear that no assumption should be made that the sender and receiver port ought to be the same. and it makes perfect sense, e.g. if you have two clients on the same machine communicating with one server, you probably want to be able to discriminate them (without having to open 2 ports on the server!) > it would be great if the pd implementation could be updated to > optionally allow using the same socket for sending and receiving. all udp implementations in Pd currently are unidirectional. however, you can create a [udpsend] to port <xyz> and, in the same patch, a [udpreceive] that listens at port <xyz>, which might help (or not). (it still would involve 2 independent sockets) nevertheless, somebody could write a bi-directional udp object, which should do no harm :-) > OSC only defines a message exchange format, but a particular > application level protocol built on top of OSC might require > bidirectional communication to communicate state changes. i totally agree. i just commented on marije's "in OSC it i |