1  |   Order by index

Jan 7, 1999, 8:21pm

With the help and suggestions of Roland and Walter in previous
postings, I've been experimenting with WFS, using the technique of
unplugging the modem, equivalent, I supposed, to a connection failure
of my provider.

AW_WORLD_DISCONNECT does help if you have an instance logged into a
world. You get the (new) reason 471 RC_CONNECTION_LOST.

It takes about a minute before you get this message. In my experience,
after getting this message, aw_wait blocks. The program responds once
every half minute approximately. aw_wait also does not return an error
code.

If the instance is only logged into the universe and not into a world
when disconnection occurs, you don't get any message at all: aw_wait
blocks as previously, and you can, in the brief moments that the
program does respond, log into any imaginary world you want, aw_enter
returns 0 SUCCESS. You'll get then the world attributes of the world
you were previously visiting.

I haven't yet experimented with disconnection caused by the world or
uniserver. I suppose aw_wait will block only if you attempt to stay in
a world that fails to connect, or the uniserver fails.

I reason that since aw_wait serves all instances in a multi-instance
case, a failure of aw_wait will affect every instance, even those
connected. Haven't tested this.

Something to work on when the 2.1 rush is over?

Any suggestions of enlightments welcome. XelaG.

Jan 7, 1999, 10:38pm

>With the help and suggestions of Roland and Walter in previous
>postings, I've been experimenting with WFS, using the technique of
>unplugging the modem, equivalent, I supposed, to a connection failure
>of my provider.
>
>AW_WORLD_DISCONNECT does help if you have an instance logged into a
>world. You get the (new) reason 471 RC_CONNECTION_LOST.
>
>It takes about a minute before you get this message. In my experience,
>after getting this message, aw_wait blocks. The program responds once
>every half minute approximately. aw_wait also does not return an error
>code.


The one minute delay in this case is a result of the fact that typically,
unplugging your modem takes a while to manifest itself within the network
layer of the operating system. Unplugging the modem does not generate any
immediate errors; rather, it appears to the system simply as a stall in the
flow of data. Eventually, the SDK will timeout after not receiving any data
from the server, and will then generate the AW_EVENT_WORLD_DISCONNECTevent.

Under other circumtances, AW_EVENT_WORLD_DISCONNECTwill be triggered much
more quickly, such as when your bot is ejected from the world (although the
reason code will be different in that case.) Also, if the world server is
shut down while your bot is inside, that typically causes an immediate error
condition on the socket so it will also cause an immediate
AW_EVENT_WORLD_DISCONNECT event as well.

aw_wait() should not block in this case. It definitely does not block in
this case when the SDK is being used by the AW browser, I have been testing
that case extensively over the last week so I am sure about that.

aw_wait() does not return an error code because it isn't an error to call
aw_wait() when you are not conneted to a world. Also, and this definitely
needs to be documented better, calling aw_wait() after the connection has
been lost (in the RC_CONNECTION_LOST case) will actually cause the SDK to
attempt to re-establish connection with the world server automatically.

>If the instance is only logged into the universe and not into a world
>when disconnection occurs, you don't get any message at all

That is correct. Loss of connection with the universe does not manifest
itself at the API level. This could probably be handled better. What your
app should do is continue to call aw_wait() periodically; it will continue
to attempt to re-establish the connection with the universe server
automatically.

aw_wait
>blocks as previously, and you can, in the brief moments that the
>program does respond, log into any imaginary world you want, aw_enter
>returns 0 SUCCESS. You'll get then the world attributes of the world
>you were previously visiting.


Whoa! That definitely does NOT sound right. I will have to check into
this.

>I haven't yet experimented with disconnection caused by the world or
>uniserver. I suppose aw_wait will block only if you attempt to stay in
>a world that fails to connect, or the uniserver fails.
>
>I reason that since aw_wait serves all instances in a multi-instance
>case, a failure of aw_wait will affect every instance, even those
>connected. Haven't tested this.
>
>Something to work on when the 2.1 rush is over?
>
>Any suggestions of enlightments welcome. XelaG.

1  |   Order by index