NetAddr

[nescivi]

Hiho,

On Sunday 09 March 2008 06:44:31 thor wrote:

> On 9 Mar 2008, at 07:16, Brian Willkie wrote:
> > Sure, but it uses otudp, which I understand is not supported by
> > cnmat any more (unless they've changed their minds). otudp is
> > suppose to be replaced by udpsend and udpreceive, but udpsend
> > doesn't have an outlet for messages sent to its port...
>
> I see, we should convince them to support this in udpsend.
>
> Otherwise, we have no chance of getting stuff back from the server???
> (like on Pd)

Please read the rest of the thread as it progressed.
You seem to be confused the same way several others have been. I posted a
helpfile as well, where I tried to clear up the confusion; if that helpfile
is still not clear, then please let me know how you understand it, so I can
try to make it even clearer.

sincerely,
Marije

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

[IOhannes m zmölnig]

nescivi wrote:

> Hiho,
>>
>> 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!)
>
> I don't see your argument here.
> We agree on this. The server listens on one port only. The clients send from
> different ports, since they cannot use the same port.

probably i got confused as i seem to remember that SC wants to respond
to the same port as it listens to (sender port == receiver port).
but this might be my inaccurate reading.

>> nevertheless, somebody could write a bi-directional udp object, which
>> should do no harm :-)
>
> unidirectionality is not the problem.

hmm, why do they always get mixed up?

> It is more that in order to be sure that messages come from the right client,
> important in open, i.e. running over an open network, configuration, that the

so is this "feature" of SC a security mechanism or a client dispatching
mechanism?

it seems like opinions here are contradictory (at least, each time i try
to address one or the other, i seem to be redirected the other way round)

> Pd send object needs to be able to specify a port from which it sends, in
> addition to to which it sends.
> OTOH, as I understood from Brent's explanation, once Pd has chosen a random
> port, it sticks with that one for as long as it keeps sending. So it would be
> possible to write some logic in SC to detect the right port on a first
> message and then continue listening only to that port.

well: Pd will open a socket once (with fixed sender and receiver port)
and use it to send any messages.
once it detects that the connection is actually closed or the user
requests a "disconnect" (it's the same naming for TCP/IP and UDP), you
will have to re-connect in order to send data again, which will
eventually give you a new sender port.


> However, in my humble opinion, that is not the most pretty solution.

it is ugly as what you are actually doing is firewall stuff. leave
firewalling to a firewall.
(feel free to do it in SC; in this case i would say the solution is
pretty enough)


> I did also propose a solution for listening to any port from a specific IP on
> the dev list a few days ago, but I did not get any feedback on that yet.

and probably allow netmasks for the IP too (if that is not already possible)

>
> In SC it is optional (you can set the NetAddr to nil in the responder), but a
> request was made to make it more specific.
> Now there are a number of solutions:
>
> * detect the port upon the first message and from there on only listen to that
> port. Requires a bit of logic written in SC by the user.
> * make use of the proposed arbitrary port solution for the responder (see
> dev-list)

i have briefly looked at the archives of sc-dev but haven't been able to
find a reference to this.

> * convince the third-party application that their osc sending should include a
> fixed and configurable port they send *from*.
>

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

[thor-2]

Hi Marije

>> I see, we should convince them to support this in udpsend.
>>
>> Otherwise, we have no chance of getting stuff back from the server???
>> (like on Pd)
>
> Please read the rest of the thread as it progressed.
> You seem to be confused the same way several others have been. I  
> posted a
> helpfile as well, where I tried to clear up the confusion; if that  
> helpfile
> is still not clear, then please let me know how you understand it,  
> so I can
> try to make it even clearer.

No, there is no confusion. I think....

I was just saying that Max can send and listen to the server (send a /
notify 1)
on the same port. You can't do that in Pd. And Brian pointed out that  
this was
not possible anymore on Max with the new objects. Which I lamented.

This had nothing to do with SC but the lack of possibility of getting  
stuff back
into Pd from the server (and now Max as well apparently). And your  
helpfile was good!

NOTE: I'm talking about SC Server, not the language. (I'm not aware  
that the
language can send to any port - only the one that you register the  
client on).

thor

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