NetAddr

View: New views
20 Messages — Rating Filter:   Alert me  
< Prev | 1 - 2 - 3 | Next >

Re: NetAddr

by Scott Wilson-8 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Perhaps 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: NetAddr

by IOhannes m zmoelnig :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

Re: NetAddr

by Dan Stowell :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi 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: NetAddr

by thor-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


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.



_______________________________________________
sc-users mailing list
sc-users@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-users

Re: NetAddr

by Dan Stowell :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

2008/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: NetAddr

by stefan kersten-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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 ;)

> 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

by nescivi :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Some parts of this message have been removed. Learn more about Nabble's security policy.
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


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: NetAddr

by andrea valle-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Some parts of this message have been removed. Learn more about Nabble's security policy.
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")).

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:

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

--------------------------------------------------
Andrea Valle
--------------------------------------------------
CIRMA - DAMS
Università degli Studi di Torino
--------------------------------------------------


"
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: NetAddr

by nescivi :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hiho,

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: NetAddr

by William Brent-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Great 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,

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



--
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

by andrea valle-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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:

Hiho,

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

--------------------------------------------------
Andrea Valle
--------------------------------------------------
CIRMA - DAMS
Università degli Studi di Torino
--------------------------------------------------


"
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

--------------------------------------------------
Andrea Valle
--------------------------------------------------
CIRMA - DAMS
Università degli Studi di Torino
--------------------------------------------------


"
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: NetAddr

by IOhannes m zmoelnig :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Quoting 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