[commit?] Server.sendQuit option

View: New views
13 Messages — Rating Filter:   Alert me  

[commit?] Server.sendQuit option

by nescivi :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hiho,

would it be ok to add an option to Server to whether or not it should be sent
a quit message, when using quitAll?

This would prevent remote servers from being quit, upon class recompilation,
which is desirable when the server runs remotely (e.g. in another city).

(Stefan Kersten originally (back in 2005) made this addition for a sound
installation of ours, but it never got proposed or committed, maybe it has be
solved already by another option?)

sincerely,
Marije


Index: build/SCClassLibrary/Common/Control/Server.sc
===================================================================
--- build/SCClassLibrary/Common/Control/Server.sc       (revision 7516)
+++ build/SCClassLibrary/Common/Control/Server.sc       (working copy)
@@ -135,7 +135,7 @@
        classvar <>local, <>internal, <>default, <>named, <>set, <>program;

        var <name, <addr, <clientID=0;
-       var <isLocal, <inProcess;
+       var <isLocal, <inProcess, <>sendQuit;
        var <serverRunning = false, <serverBooting=false,
bootNotifyFirst=false;
        var <>options,<>latency = 0.2,<dumpMode=0, <notified=true;
        var <nodeAllocator;
@@ -550,7 +550,13 @@
        }

        *quitAll {
-               set.do({ arg server; if(server.isLocal or:
{server.inProcess} ) {server.quit}; })
+               set.do({ arg server;
+                       if ((server.sendQuit === true)
+                               or: {server.sendQuit.isNil and:
{server.isLocal or: {server.inProcess}}}) {
+                               server.quit
+                       };
+               })
+               //              set.do({ arg server; if(server.isLocal or:
{server.inProcess} ) {server.quit}; })
        }
        *killAll {
                // if you see Exception in World_OpenUDP: unable to bind udp
socket
_______________________________________________
Sc-devel mailing list
Sc-devel@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

Re: [commit?] Server.sendQuit option

by James Harkins-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Currently Server.quitAll should not try to quit remote servers. Do you find that it does otherwise?

I tested on my machine by doing (substituting my real machine name for "my-computer")

z = Server(\test, NetAddr("my-computer.local", 57109));

z.isLocal answered false, so I started scsynth at the command line with scsynth -u 57109 -b 1026. 

Quitting SuperCollider.app did not stop the scsynth instance. So at this point I don't see the benefit of this change -- it might give a bit more control, or allow you to specify a local server that should not be quit automatically, but for the stated purpose (protecting remote servers from autoquit) the app already handles that.

hjh

On Apr 19, 2008, at 6:09 PM, nescivi wrote:

Hiho,

would it be ok to add an option to Server to whether or not it should be sent 
a quit message, when using quitAll?

This would prevent remote servers from being quit, upon class recompilation, 
which is desirable when the server runs remotely (e.g. in another city).

(Stefan Kersten originally (back in 2005) made this addition for a sound 
installation of ours, but it never got proposed or committed, maybe it has be 
solved already by another option?)

sincerely,
Marije


: H. James Harkins

: jamshark70@...

: http://www.dewdrop-world.net

.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:


"Come said the Muse,

Sing me a song no poet has yet chanted,

Sing me the universal."  -- Whitman



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

Re: [commit?] Server.sendQuit option

by nescivi :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

On Sunday 20 April 2008 12:17:19 James Harkins wrote:
> Currently Server.quitAll should not try to quit remote servers. Do
> you find that it does otherwise?

Ah, I just remembered why exactly we needed it... we were using a tunneling  
ruby script to escape any firewalls we might have along the way, so the ruby
script was pretending to be a local server.

So actually the feature would be to have local servers not sent quit, which
can be beneficial also in another situation, e.g. when you have to recompile
the lang during a performance, and want to keep the sound running, so no one
notices.

sincerely,
Marije

> I tested on my machine by doing (substituting my real machine name
> for "my-computer")
>
> z = Server(\test, NetAddr("my-computer.local", 57109));
>
> z.isLocal answered false, so I started scsynth at the command line
> with scsynth -u 57109 -b 1026.
>
> Quitting SuperCollider.app did not stop the scsynth instance. So at
> this point I don't see the benefit of this change -- it might give a
> bit more control, or allow you to specify a local server that should
> not be quit automatically, but for the stated purpose (protecting
> remote servers from autoquit) the app already handles that.
>
> hjh
>
> On Apr 19, 2008, at 6:09 PM, nescivi wrote:
> > Hiho,
> >
> > would it be ok to add an option to Server to whether or not it
> > should be sent
> > a quit message, when using quitAll?
> >
> > This would prevent remote servers from being quit, upon class
> > recompilation,
> > which is desirable when the server runs remotely (e.g. in another
> > city).
> >
> > (Stefan Kersten originally (back in 2005) made this addition for a
> > sound
> > installation of ours, but it never got proposed or committed, maybe
> > it has be
> > solved already by another option?)
> >
> > sincerely,
> > Marije
> >
> : H. James Harkins
> : jamshark70@...
> : http://www.dewdrop-world.net
>
> .::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:
>
> "Come said the Muse,
> Sing me a song no poet has yet chanted,
> Sing me the universal."  -- Whitman


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

Re: [commit?] Server.sendQuit option

by Josh Parmenter :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

But how would the lang know then that the server is running after re-
compile?

I like the idea, but I think there will have to be some way to handle  
book-keeping (especially since there are a number of classes that keep  
track of things on a server).

Best,

Josh

On Apr 20, 2008, at 11:09 AM, nescivi wrote:

> Hi,
>
> On Sunday 20 April 2008 12:17:19 James Harkins wrote:
>> Currently Server.quitAll should not try to quit remote servers. Do
>> you find that it does otherwise?
>
> Ah, I just remembered why exactly we needed it... we were using a  
> tunneling
> ruby script to escape any firewalls we might have along the way, so  
> the ruby
> script was pretending to be a local server.
>
> So actually the feature would be to have local servers not sent  
> quit, which
> can be beneficial also in another situation, e.g. when you have to  
> recompile
> the lang during a performance, and want to keep the sound running,  
> so no one
> notices.
>
> sincerely,
> Marije
>
>> I tested on my machine by doing (substituting my real machine name
>> for "my-computer")
>>
>> z = Server(\test, NetAddr("my-computer.local", 57109));
>>
>> z.isLocal answered false, so I started scsynth at the command line
>> with scsynth -u 57109 -b 1026.
>>
>> Quitting SuperCollider.app did not stop the scsynth instance. So at
>> this point I don't see the benefit of this change -- it might give a
>> bit more control, or allow you to specify a local server that should
>> not be quit automatically, but for the stated purpose (protecting
>> remote servers from autoquit) the app already handles that.
>>
>> hjh
>>
>> On Apr 19, 2008, at 6:09 PM, nescivi wrote:
>>> Hiho,
>>>
>>> would it be ok to add an option to Server to whether or not it
>>> should be sent
>>> a quit message, when using quitAll?
>>>
>>> This would prevent remote servers from being quit, upon class
>>> recompilation,
>>> which is desirable when the server runs remotely (e.g. in another
>>> city).
>>>
>>> (Stefan Kersten originally (back in 2005) made this addition for a
>>> sound
>>> installation of ours, but it never got proposed or committed, maybe
>>> it has be
>>> solved already by another option?)
>>>
>>> sincerely,
>>> Marije
>>>
>> : H. James Harkins
>> : jamshark70@...
>> : http://www.dewdrop-world.net
>>
>> .::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:
>>
>> "Come said the Muse,
>> Sing me a song no poet has yet chanted,
>> Sing me the universal."  -- Whitman
>
>
> _______________________________________________
> Sc-devel mailing list
> Sc-devel@...
> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own  
interpretation of how modern society is structured: whether actively  
or passively, consciously or unconsciously, he makes choices in this  
regard. He may be conservative or he may subject himself to continual  
renewal; or he may strive for a revolutionary, historical or social  
palingenesis." - Luigi Nono
*/

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

Re: [commit?] Server.sendQuit option

by nescivi :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi Josh,

On Sunday 20 April 2008 14:38:24 Josh Parmenter wrote:
> But how would the lang know then that the server is running after re-
> compile?

hmmm...
it could look for it using zeroconf (or rendezvous, or whatever it is called).

> I like the idea, but I think there will have to be some way to handle
> book-keeping (especially since there are a number of classes that keep
> track of things on a server).

Sure, you'd have to be prepared for it, somehow...
(maybe read your history log and try and find back all the synths to the
server?)
If I were to use the option, I would surely find some way to do it, given
time.

sincerely,
Marije


>
> Best,
>
> Josh
>
> On Apr 20, 2008, at 11:09 AM, nescivi wrote:
> > Hi,
> >
> > On Sunday 20 April 2008 12:17:19 James Harkins wrote:
> >> Currently Server.quitAll should not try to quit remote servers. Do
> >> you find that it does otherwise?
> >
> > Ah, I just remembered why exactly we needed it... we were using a
> > tunneling
> > ruby script to escape any firewalls we might have along the way, so
> > the ruby
> > script was pretending to be a local server.
> >
> > So actually the feature would be to have local servers not sent
> > quit, which
> > can be beneficial also in another situation, e.g. when you have to
> > recompile
> > the lang during a performance, and want to keep the sound running,
> > so no one
> > notices.
> >
> > sincerely,
> > Marije
> >
> >> I tested on my machine by doing (substituting my real machine name
> >> for "my-computer")
> >>
> >> z = Server(\test, NetAddr("my-computer.local", 57109));
> >>
> >> z.isLocal answered false, so I started scsynth at the command line
> >> with scsynth -u 57109 -b 1026.
> >>
> >> Quitting SuperCollider.app did not stop the scsynth instance. So at
> >> this point I don't see the benefit of this change -- it might give a
> >> bit more control, or allow you to specify a local server that should
> >> not be quit automatically, but for the stated purpose (protecting
> >> remote servers from autoquit) the app already handles that.
> >>
> >> hjh
> >>
> >> On Apr 19, 2008, at 6:09 PM, nescivi wrote:
> >>> Hiho,
> >>>
> >>> would it be ok to add an option to Server to whether or not it
> >>> should be sent
> >>> a quit message, when using quitAll?
> >>>
> >>> This would prevent remote servers from being quit, upon class
> >>> recompilation,
> >>> which is desirable when the server runs remotely (e.g. in another
> >>> city).
> >>>
> >>> (Stefan Kersten originally (back in 2005) made this addition for a
> >>> sound
> >>> installation of ours, but it never got proposed or committed, maybe
> >>> it has be
> >>> solved already by another option?)
> >>>
> >>> sincerely,
> >>> Marije
_______________________________________________
Sc-devel mailing list
Sc-devel@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

Re: [commit?] Server.sendQuit option

by Josh Parmenter :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Apr 20, 2008, at 11:46 AM, nescivi wrote:

> Hi Josh,
>
> On Sunday 20 April 2008 14:38:24 Josh Parmenter wrote:
>> But how would the lang know then that the server is running after re-
>> compile?
>
> hmmm...
> it could look for it using zeroconf (or rendezvous, or whatever it  
> is called).
>
>> I like the idea, but I think there will have to be some way to handle
>> book-keeping (especially since there are a number of classes that  
>> keep
>> track of things on a server).
>
> Sure, you'd have to be prepared for it, somehow...
> (maybe read your history log and try and find back all the synths to  
> the
> server?)
> If I were to use the option, I would surely find some way to do it,  
> given
> time.
>
Perhaps if a Server has the isLocalDontForTheLoveOfAllThingsQuit flag  
set, if can poll the status of there Server (is it running, collect  
nodeIDs, allocated buffer ids, etc) and, after the recompile, reset  
these states for Objects that need it (nodeAllocator, bufferAllocator,  
etc.). This can probably actually be done on the Lang side itself.  
Since it is a special case, it shouldn't break anyone's code.

Josh

> sincerely,
> Marije
>
>
>>
>> Best,
>>
>> Josh
>>
>> On Apr 20, 2008, at 11:09 AM, nescivi wrote:
>>> Hi,
>>>
>>> On Sunday 20 April 2008 12:17:19 James Harkins wrote:
>>>> Currently Server.quitAll should not try to quit remote servers. Do
>>>> you find that it does otherwise?
>>>
>>> Ah, I just remembered why exactly we needed it... we were using a
>>> tunneling
>>> ruby script to escape any firewalls we might have along the way, so
>>> the ruby
>>> script was pretending to be a local server.
>>>
>>> So actually the feature would be to have local servers not sent
>>> quit, which
>>> can be beneficial also in another situation, e.g. when you have to
>>> recompile
>>> the lang during a performance, and want to keep the sound running,
>>> so no one
>>> notices.
>>>
>>> sincerely,
>>> Marije
>>>
>>>> I tested on my machine by doing (substituting my real machine name
>>>> for "my-computer")
>>>>
>>>> z = Server(\test, NetAddr("my-computer.local", 57109));
>>>>
>>>> z.isLocal answered false, so I started scsynth at the command line
>>>> with scsynth -u 57109 -b 1026.
>>>>
>>>> Quitting SuperCollider.app did not stop the scsynth instance. So at
>>>> this point I don't see the benefit of this change -- it might  
>>>> give a
>>>> bit more control, or allow you to specify a local server that  
>>>> should
>>>> not be quit automatically, but for the stated purpose (protecting
>>>> remote servers from autoquit) the app already handles that.
>>>>
>>>> hjh
>>>>
>>>> On Apr 19, 2008, at 6:09 PM, nescivi wrote:
>>>>> Hiho,
>>>>>
>>>>> would it be ok to add an option to Server to whether or not it
>>>>> should be sent
>>>>> a quit message, when using quitAll?
>>>>>
>>>>> This would prevent remote servers from being quit, upon class
>>>>> recompilation,
>>>>> which is desirable when the server runs remotely (e.g. in another
>>>>> city).
>>>>>
>>>>> (Stefan Kersten originally (back in 2005) made this addition for a
>>>>> sound
>>>>> installation of ours, but it never got proposed or committed,  
>>>>> maybe
>>>>> it has be
>>>>> solved already by another option?)
>>>>>
>>>>> sincerely,
>>>>> Marije
> _______________________________________________
> Sc-devel mailing list
> Sc-devel@...
> http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own  
interpretation of how modern society is structured: whether actively  
or passively, consciously or unconsciously, he makes choices in this  
regard. He may be conservative or he may subject himself to continual  
renewal; or he may strive for a revolutionary, historical or social  
palingenesis." - Luigi Nono
*/

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

Re: [commit?] Server.sendQuit option

by nescivi :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hiho,

On Sunday 20 April 2008 14:49:22 you wrote:

> > On Sunday 20 April 2008 14:38:24 Josh Parmenter wrote:
> >> But how would the lang know then that the server is running after re-
> >> compile?
> >
> > hmmm...
> > it could look for it using zeroconf (or rendezvous, or whatever it
> > is called).
> >
> >> I like the idea, but I think there will have to be some way to handle
> >> book-keeping (especially since there are a number of classes that
> >> keep
> >> track of things on a server).
> >
> > Sure, you'd have to be prepared for it, somehow...
> > (maybe read your history log and try and find back all the synths to
> > the
> > server?)
> > If I were to use the option, I would surely find some way to do it,
> > given
> > time.
>
> Perhaps if a Server has the isLocalDontForTheLoveOfAllThingsQuit flag
> set, if can poll the status of there Server (is it running, collect
> nodeIDs, allocated buffer ids, etc) and, after the recompile, reset
> these states for Objects that need it (nodeAllocator, bufferAllocator,
> etc.). This can probably actually be done on the Lang side itself.
> Since it is a special case, it shouldn't break anyone's code.

indeed.

Don't you think that the name you propose for the flag is a bit long
though? ;)

sincerely,
marije

>
> Josh
>
> > sincerely,
> > Marije
> >
> >> Best,
> >>
> >> Josh
> >>
> >> On Apr 20, 2008, at 11:09 AM, nescivi wrote:
> >>> Hi,
> >>>
> >>> On Sunday 20 April 2008 12:17:19 James Harkins wrote:
> >>>> Currently Server.quitAll should not try to quit remote servers. Do
> >>>> you find that it does otherwise?
> >>>
> >>> Ah, I just remembered why exactly we needed it... we were using a
> >>> tunneling
> >>> ruby script to escape any firewalls we might have along the way, so
> >>> the ruby
> >>> script was pretending to be a local server.
> >>>
> >>> So actually the feature would be to have local servers not sent
> >>> quit, which
> >>> can be beneficial also in another situation, e.g. when you have to
> >>> recompile
> >>> the lang during a performance, and want to keep the sound running,
> >>> so no one
> >>> notices.
> >>>
> >>> sincerely,
> >>> Marije
> >>>
> >>>> I tested on my machine by doing (substituting my real machine name
> >>>> for "my-computer")
> >>>>
> >>>> z = Server(\test, NetAddr("my-computer.local", 57109));
> >>>>
> >>>> z.isLocal answered false, so I started scsynth at the command line
> >>>> with scsynth -u 57109 -b 1026.
> >>>>
> >>>> Quitting SuperCollider.app did not stop the scsynth instance. So at
> >>>> this point I don't see the benefit of this change -- it might
> >>>> give a
> >>>> bit more control, or allow you to specify a local server that
> >>>> should
> >>>> not be quit automatically, but for the stated purpose (protecting
> >>>> remote servers from autoquit) the app already handles that.
> >>>>
> >>>> hjh
> >>>>
> >>>> On Apr 19, 2008, at 6:09 PM, nescivi wrote:
> >>>>> Hiho,
> >>>>>
> >>>>> would it be ok to add an option to Server to whether or not it
> >>>>> should be sent
> >>>>> a quit message, when using quitAll?
> >>>>>
> >>>>> This would prevent remote servers from being quit, upon class
> >>>>> recompilation,
> >>>>> which is desirable when the server runs remotely (e.g. in another
> >>>>> city).
> >>>>>
> >>>>> (Stefan Kersten originally (back in 2005) made this addition for a
> >>>>> sound
> >>>>> installation of ours, but it never got proposed or committed,
> >>>>> maybe
> >>>>> it has be
> >>>>> solved already by another option?)
> >>>>>
> >>>>> sincerely,
> >>>>> Marije
_______________________________________________
Sc-devel mailing list
Sc-devel@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

Re: [commit?] Server.sendQuit option

by Josh Parmenter :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Apr 20, 2008, at 11:56 AM, nescivi wrote:

> Don't you think that the name you propose for the flag is a bit long
> though? ;)


It will certainly keep people from setting it accidently.

Josh

******************************************
/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own  
interpretation of how modern society is structured: whether actively  
or passively, consciously or unconsciously, he makes choices in this  
regard. He may be conservative or he may subject himself to continual  
renewal; or he may strive for a revolutionary, historical or social  
palingenesis." - Luigi Nono
*/

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

Re: [commit?] Server.sendQuit option

by James Harkins-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Apr 20, 2008, at 2:46 PM, nescivi wrote:

On Sunday 20 April 2008 14:38:24 Josh Parmenter wrote:
But how would the lang know then that the server is running after re-
compile?

hmmm...
it could look for it using zeroconf (or rendezvous, or whatever it is called).

Starting the aliveThread should be sufficient. If it sends /status to the server and gets a reply, it knows the server is running.

hjh


: H. James Harkins

: jamshark70@...

: http://www.dewdrop-world.net

.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:


"Come said the Muse,

Sing me a song no poet has yet chanted,

Sing me the universal."  -- Whitman



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

Re: [commit?] Server.sendQuit option

by James Harkins-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Apr 20, 2008, at 2:09 PM, nescivi wrote:

On Sunday 20 April 2008 12:17:19 James Harkins wrote:
Currently Server.quitAll should not try to quit remote servers. Do
you find that it does otherwise?

Ah, I just remembered why exactly we needed it... we were using a tunneling  
ruby script to escape any firewalls we might have along the way, so the ruby 
script was pretending to be a local server.

Another way to handle this is, if you know the name or IP address of the local machine, create the NetAddr using that instead of the usual 127.0.0.1. Server decides whether an instance is local or not by comparing the address to 127.0.0.1. It doesn't check whether other IP addresses actually point to the local machine or not.

So it's already possible to have a "non-local" server that sends messages to a process running on the local machine.

I do kind of see what you're after, but I'm not totally convinced it's necessary because there is still a way to do what's needed in this special case. I wouldn't stand in the way if others decide it's a definitely-needed new feature.

hjh


: H. James Harkins

: jamshark70@...

: http://www.dewdrop-world.net

.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:


"Come said the Muse,

Sing me a song no poet has yet chanted,

Sing me the universal."  -- Whitman



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

Re: [commit?] Server.sendQuit option

by Dan Stowell :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

2008/4/20, James Harkins <jamshark70@...>:

>
> On Apr 20, 2008, at 2:09 PM, nescivi wrote:
>
> On Sunday 20 April 2008 12:17:19 James Harkins wrote:
> Currently Server.quitAll should not try to quit remote servers. Do
> you find that it does otherwise?
>
> Ah, I just remembered why exactly we needed it... we were using a tunneling
> ruby script to escape any firewalls we might have along the way, so the ruby
> script was pretending to be a local server.
>
> Another way to handle this is, if you know the name or IP address of the
> local machine, create the NetAddr using that instead of the usual 127.0.0.1.
> Server decides whether an instance is local or not by comparing the address
> to 127.0.0.1. It doesn't check whether other IP addresses actually point to
> the local machine or not.
>
> So it's already possible to have a "non-local" server that sends messages to
> a process running on the local machine.
>
> I do kind of see what you're after, but I'm not totally convinced it's
> necessary because there is still a way to do what's needed in this special
> case. I wouldn't stand in the way if others decide it's a definitely-needed
> new feature.

To me it all sounds tricky/messy to implement, and not very
well-motivated, sorry. Hopefully JH's IP address trick caters for the
(unusual) situation.

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

Re: [commit?] Server.sendQuit option

by nescivi :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Monday 21 April 2008 06:51:27 Dan Stowell wrote:

> 2008/4/20, James Harkins <jamshark70@...>:
> > On Apr 20, 2008, at 2:09 PM, nescivi wrote:
> >
> > On Sunday 20 April 2008 12:17:19 James Harkins wrote:
> > Currently Server.quitAll should not try to quit remote servers. Do
> > you find that it does otherwise?
> >
> > Ah, I just remembered why exactly we needed it... we were using a
> > tunneling ruby script to escape any firewalls we might have along the
> > way, so the ruby script was pretending to be a local server.
> >
> > Another way to handle this is, if you know the name or IP address of the
> > local machine, create the NetAddr using that instead of the usual
> > 127.0.0.1. Server decides whether an instance is local or not by
> > comparing the address to 127.0.0.1. It doesn't check whether other IP
> > addresses actually point to the local machine or not.
> >
> > So it's already possible to have a "non-local" server that sends messages
> > to a process running on the local machine.
> >
> > I do kind of see what you're after, but I'm not totally convinced it's
> > necessary because there is still a way to do what's needed in this
> > special case. I wouldn't stand in the way if others decide it's a
> > definitely-needed new feature.
>
> To me it all sounds tricky/messy to implement, and not very
> well-motivated, sorry. Hopefully JH's IP address trick caters for the
> (unusual) situation.

Hmm...
with a small fix to NetLib this would work, I guess...
(this fix is necessary anyway for myIP to work on Linux, since normally
ifconfig is not in the path for the normal user, but lies in /sbin/).

I'll commit it to the quarks if there is no objection.

+ NetAddr{
*myIP { |prefix=""|
                var j, k, res, bc;
                res = Pipe.findValuesForKey(prefix++"ifconfig", "inet");
...


sincerely,
Marije
_______________________________________________
Sc-devel mailing list
Sc-devel@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel

Re: [commit?] Server.sendQuit option

by nescivi :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Monday 21 April 2008 18:03:30 nescivi wrote:

> On Monday 21 April 2008 06:51:27 Dan Stowell wrote:
> > 2008/4/20, James Harkins <jamshark70@...>:
> > > On Apr 20, 2008, at 2:09 PM, nescivi wrote:
> > >
> > > On Sunday 20 April 2008 12:17:19 James Harkins wrote:
> > > Currently Server.quitAll should not try to quit remote servers. Do
> > > you find that it does otherwise?
> > >
> > > Ah, I just remembered why exactly we needed it... we were using a
> > > tunneling ruby script to escape any firewalls we might have along the
> > > way, so the ruby script was pretending to be a local server.
> > >
> > > Another way to handle this is, if you know the name or IP address of
> > > the local machine, create the NetAddr using that instead of the usual
> > > 127.0.0.1. Server decides whether an instance is local or not by
> > > comparing the address to 127.0.0.1. It doesn't check whether other IP
> > > addresses actually point to the local machine or not.
> > >
> > > So it's already possible to have a "non-local" server that sends
> > > messages to a process running on the local machine.
> > >
> > > I do kind of see what you're after, but I'm not totally convinced it's
> > > necessary because there is still a way to do what's needed in this
> > > special case. I wouldn't stand in the way if others decide it's a
> > > definitely-needed new feature.
> >
> > To me it all sounds tricky/messy to implement, and not very
> > well-motivated, sorry. Hopefully JH's IP address trick caters for the
> > (unusual) situation.
>
> Hmm...
> with a small fix to NetLib this would work, I guess...
> (this fix is necessary anyway for myIP to work on Linux, since normally
> ifconfig is not in the path for the normal user, but lies in /sbin/).

ok, it works.
I'll commit the necessary changes to NetLib for retrieving the IP of the host.

sincerely,
Marije
_______________________________________________
Sc-devel mailing list
Sc-devel@...
http://lists.create.ucsb.edu/mailman/listinfo/sc-devel
LightInTheBox - Buy quality products at wholesale price