Re: Cannot Connect to the collaborative (red screen)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Cannot Connect to the collaborative (red screen)

Howard Stearns
Hi Christopher,

The specific thing you need to be able to do is initiate an outgoing connection
to port 5910 on www.croquetcollaborative.org (aka 66.170.3.34).

Sometimes a failure to connect is caused by the continuity server being stuck in
an error, so that it cannot provide the current definition of the world -- which
you wouldn't want anyway because it produced an error! We're working on a way to
have the entire replicated simulation reset (everyone) to the last saved version
when there is an error. In the mean time, someone like me has to reset the
continuity server when it's down, which means that someone has to tell us by
sending mail to [hidden email] as you did. (Of course, we want
there to be no errors, but IT happens.) In any case, I've confirmed that it is
live at the moment.

There have been a couple of bug fixes lately, but these should not effect
connecting. We'll put out a new version after the SDK release, but if you're
getting errors with some of the more advanced features and you're familiar with
Squeak, you can update yourself to the latest Wisconsin package in Monticello.

L. Christopher Bird wrote:

> To Whom it may concern,
>
> I am interested in trying out croquet, yet cannot connect to the
> collaborative.
>
> The note that comes with the client says that I may have to configure my
> firewall, but fails to mention what port(s) to open.
>
> The note also says to contact you at this address if I cannot connect,
> so I am doing so.  It doesn't say what kind of information you need from
> me, so I am providing a few things that you might need, but I dunno.
>
> OS: Windows
> IP: 69.145.212.12 <http://69.145.212.12>
>
> Image: Croquet.1.0.17.7.image
>
> After several (like on the order of 10) minutes I get the following error:
>  
> Error: key not found.
>
> Any help would be appreciated.
>
> -- Christopher
>
>  
> *
> *

--
Howard Stearns
University of Wisconsin - Madison
Division of Information Technology
mailto:[hidden email]
jabber:[hidden email]
voice:+1-608-262-3724
Reply | Threaded
Open this post in threaded view
|

Re: Re: Cannot Connect to the collaborative (red screen)

haggai Goldfarb
Hi Howard,

What if you close all the portals between islands (keeping content intact) kind of like shutting down all the doors in a  "sinking-ship" (or sub) scenario.  My guess is that the first thing you would want to do (since this is 3d...) is to immediately cut-down on your computation resources.  just  a thought...

haggai

 
Haggai Goldfarb
LiquidBits
office: 617.945.5050
cell: 818.648.5158
[hidden email]


----- Original Message ----
From: Howard Stearns <[hidden email]>
To: L. Christopher Bird <[hidden email]>
Cc: [hidden email]
Sent: Thursday, February 22, 2007 12:05:33 PM
Subject: [croquet-dev] Re: Cannot Connect to the collaborative (red screen)

Hi Christopher,

The specific thing you need to be able to do is initiate an outgoing connection
to port 5910 on www.croquetcollaborative.org (aka 66.170.3.34).

Sometimes a failure to connect is caused by the continuity server being stuck in
an error, so that it cannot provide the current definition of the world -- which
you wouldn't want anyway because it produced an error! We're working on a way to
have the entire replicated simulation reset (everyone) to the last saved version
when there is an error. In the mean time, someone like me has to reset the
continuity server when it's down, which means that someone has to tell us by
sending mail to [hidden email] as you did. (Of course, we want
there to be no errors, but IT happens.) In any case, I've confirmed that it is
live at the moment.

There have been a couple of bug fixes lately, but these should not effect
connecting. We'll put out a new version after the SDK release, but if you're
getting errors with some of the more advanced features and you're familiar with
Squeak, you can update yourself to the latest Wisconsin package in Monticello.

L. Christopher Bird wrote:

> To Whom it may concern,
>
> I am interested in trying out croquet, yet cannot connect to the
> collaborative.
>
> The note that comes with the client says that I may have to configure my
> firewall, but fails to mention what port(s) to open.
>
> The note also says to contact you at this address if I cannot connect,
> so I am doing so.  It doesn't say what kind of information you need from
> me, so I am providing a few things that you might need, but I dunno.
>
> OS: Windows
> IP: 69.145.212.12 <http://69.145.212.12>
>
> Image: Croquet.1.0.17.7.image
>
> After several (like on the order of 10) minutes I get the following error:
>  
> Error: key not found.
>
> Any help would be appreciated.
>
> -- Christopher
>
>  
> *
> *

--
Howard Stearns
University of Wisconsin - Madison
Division of Information Technology
mailto:[hidden email]
jabber:[hidden email]
voice:+1-608-262-3724

Reply | Threaded
Open this post in threaded view
|

closing down non-active worlds [was: Cannot Connect to the collaborative (red screen)]

Howard Stearns
I am certain that this is not the source of my immediate difficulty in safely
having a collaboration reset on error.

It may be useful in other "emergency" situations, but I'm not really seeing how(1):

  - Closing the doors doesn't stop the other worlds from processing. Once you
have a world, you process its messages whether it is rendering or not. And the
intention is that rendering itself is not supposed to effect correctness, nor
have too great an effect on CPU performance.

  - When "an error" has occurred, we don't know much except for the fact that
our Croquet model isn't valid at that point. So I'm not sure what it would mean
to try to define a new state/history-set based on an invalid model. My attempts
to reset are based on the idea of abandoning the current history-set and going
back to the last saved state.

Now, for a WORKING harness involving several simulations, I do think there's
good reason to abandon processing of worlds that you were in but are not in any
longer. You can always rejoin in the normal way.  I think it would make sense to
combine this with a mechanism that joined worlds that you might be ABOUT to
join. The algorithm might be to join anything that can be reached in one
topological hop from a rendered space, and abandon anything that isn't.

-----------
(1)As it turns out, I actually have a degree in ship design and little practice.
I might be so focused on the literal meaning of your analogy that my mind isn't
open to making a connection.  On a real ship, closing the bulkhead doors doesn't
usually close the myriad pipes between compartments, so there's still
"communication" between. It's usually not enough to rapidly sink the ship, but
it can be, if indirectly. c.f. USS Thresher.

haggai Goldfarb wrote:

> Hi Howard,
>
> What if you close all the portals between islands (keeping content
> intact) kind of like shutting down all the doors in a  "sinking-ship"
> (or sub) scenario.  My guess is that the first thing you would want to
> do (since this is 3d...) is to immediately cut-down on your computation
> resources.  just  a thought...
>
> haggai
>
Reply | Threaded
Open this post in threaded view
|

Re: closing down non-active worlds [was: Cannot Connect to the collaborative (red screen)]

haggai Goldfarb
Howard,

Point well taken. My apology. The analogy - wrong choice of words.  I meant nothing by it. Merely to describe a "crash" or "catastrophic"  situation. 

Sorry

haggai

 
Haggai Goldfarb
LiquidBits
office: 617.945.5050
cell: 818.648.5158
[hidden email]


----- Original Message ----
From: Howard Stearns <[hidden email]>
To: [hidden email]; haggai Goldfarb <[hidden email]>
Sent: Thursday, February 22, 2007 1:15:41 PM
Subject: closing down non-active worlds [was: Cannot Connect to the collaborative (red screen)]

I am certain that this is not the source of my immediate difficulty in safely
having a collaboration reset on error.

It may be useful in other "emergency" situations, but I'm not really seeing how(1):

  - Closing the doors doesn't stop the other worlds from processing. Once you
have a world, you process its messages whether it is rendering or not. And the
intention is that rendering itself is not supposed to effect correctness, nor
have too great an effect on CPU performance.

  - When "an error" has occurred, we don't know much except for the fact that
our Croquet model isn't valid at that point. So I'm not sure what it would mean
to try to define a new state/history-set based on an invalid model. My attempts
to reset are based on the idea of abandoning the current history-set and going
back to the last saved state.

Now, for a WORKING harness involving several simulations, I do think there's
good reason to abandon processing of worlds that you were in but are not in any
longer. You can always rejoin in the normal way.  I think it would make sense to
combine this with a mechanism that joined worlds that you might be ABOUT to
join. The algorithm might be to join anything that can be reached in one
topological hop from a rendered space, and abandon anything that isn't.

-----------
(1)As it turns out, I actually have a degree in ship design and little practice.
I might be so focused on the literal meaning of your analogy that my mind isn't
open to making a connection.  On a real ship, closing the bulkhead doors doesn't
usually close the myriad pipes between compartments, so there's still
"communication" between. It's usually not enough to rapidly sink the ship, but
it can be, if indirectly. c.f. USS Thresher.

haggai Goldfarb wrote:

> Hi Howard,
>
> What if you close all the portals between islands (keeping content
> intact) kind of like shutting down all the doors in a  "sinking-ship"
> (or sub) scenario.  My guess is that the first thing you would want to
> do (since this is 3d...) is to immediately cut-down on your computation
> resources.  just  a thought...
>
> haggai
>