Nicolas,
On my Lua client I used a table of callbacks that's indexed by
challenge ID. I then compare the challenge ID in the response with
this table to get the proper callback.
You're right it's CLOSE not QUIT my mistake.
Nathan.
On Tue Nov 15 16:28:17 2011, Nicolas Guibert wrote:
All this is done by APE-jsf by default (I believe QUIT is actually
CLOSE though).
And indeed, I see all this in Firebug.
The problem is to link what is received with what was sent. A CLOSE is
received after each successful request. I have just tested the
sendResponse, it actually replaces the CLOSE, so no overhead in most
cases in not all. Good point.
After thinking more about it (while writing this message), it seems
that this can work with sendResponse. A simple catch of the response
on the client side will do the trick. However, maybe the CHL is not
the correct way to do it. How do I know what CHL was associated with
my command in the first place?
Thanks again.
2011/11/15 Nathan Tran<[email protected]
<mailto:[email protected]>>
I assume that you're using long polling. In that case the http
connection is kept open with the server. If there is no traffic
in 35 seconds (you can set this), then the server will
automatically disconnect the user (LEFT raw). So it's the
client's responsibility to keep a fresh http connection with the
server. The JS client opens a new http connection with the server
say after every 30s of inactivity. The server receives this
connection and immediately disconnects the previous one and then
sending a QUIT raw for that previous connection. That's the
response you're seeing in Firebug.
Nathan.
On Tue Nov 15 15:43:01 2011, Nicolas Guibert wrote:
Many thanks.
It seems that this sendResponse can probably help do what I
want, but isn't there already a response sent by the server on
every command. I think there is.
2011/11/15 Nicolas Guibert<[email protected]
<mailto:[email protected]>
<mailto:ioa.guibert@__googlemail.com
<mailto:[email protected]>>>
Sounds great. I'll have a look at this.
2011/11/15 Nathan Tran<[email protected]
<mailto:[email protected]>
<mailto:[email protected]<mailto:[email protected]>>>
Nicolas,
I am not sure if you are aware of the sendResponse()
function
on the server. When you call the sendResponse()
function the
server automatically injects the challenge ID into the
response RAW. On the client side you can acknowledge this
response as a direct response to a particular command
you sent
earlier. I used this on the client side (Lua not JS)
to make
callbacks asynchronously.
Hope this helps.
Nathan.
On Tue Nov 15 15:17:04 2011, Nicolas wrote:
Hi,
Great to see someone interested by the subject :)
I am not delving into the APE js, because I am
pretty sure
it would
take me too much time to figure it out and also
because if
they update
it, I'll have to update my code too.
I have just added a check_raw_id() function at the
beginning of every
onraw that I am interested in (the messages that I
need to
check). In
this check_raw_id() function, I send the
acknowledgement
and also
check that the raw_id is the one that I am expecting
(because I want
to receive them in order), not one that is too early or
one that was
sent (and actually received) twice.
On the server side, I send the raws via a
send_custom_raw() function
that keeps track of the content of the raw and of
its id
(raw_id).
When an ACK_REC is received from the client, it deletes
the message in
the storing array. Every x seconds, I test if there are
"old" messages
that have not yet received their ACK_REC and if so, I
resend them.
I could do something similar for the client to server
exchanges, but
is that really necessary? I am pretty sure that we can
avoid this
overhead as the information of whether the command was
received by the
server is pretty much there. The problem is that I
don't
really know
how to extract it. Any ideas welcome?
On 15 nov, 18:35,
chrismdodson<[email protected]
<mailto:[email protected]>
<mailto:christophermarkdod...@__googlemail.com
<mailto:[email protected]>>>
wrote:
Nicolas:
This is great, that you are creating an assured
delivery, and
maintenance of message order. Without this
there are
so many
applications that will not be able to use push -
particularly those
that want to initially deliver state to a
client - and
then updates -
to avoid having to send state with each 'push',
with
all the extra
traffic this generates.
Presume you are making changes to the Javascript
client and the
backend code to enable this ?
Brgrds, Chris
On Nov 10, 2:39 pm,
Nicolas<ioa.guib...@__googlema__il.com
<http://googlemail.com>
<mailto:ioa.guib...@__googlemail.com
<mailto:[email protected]>>> wrote:
Hi,
Is there a little bit of acknowledgement of
receipt in APE?
Client sending to server:
I believe there is not much problem as the
server
returns something on
every custom command sent by the client
(and can
even send an error
code or whatever is needed)
Server sending to client:
That seems more complicated to me. Is there any
way at all (without
adding my own layer) to know that a
command/message sent by the server
has been received by the client. I have
started to
implement my custom
acknowledgement of receipt but realize that
there
might already be
some hidden indicator that would just let
me know
this, without much
more trouble.
In any case, any thoughts on this subject truly
appreciated.
I really need to check that a raw has been
received. I am working on a
board game server and I can't allow that a move
gets lost in
cyberspace, as it happens currently, with a
relatively high frequency
(maybe 1 out of 500 messages for some) for some
unlucky players,
resulting in one game out of 10 freezing
for them.
On my computer
however, I have never seen a frozen game which
confirms that the
quality of the client Internet connection
is the
limiting factor here.
Thanks in advance.
Nicolas.
-- You received this message because you are
subscribed to the Google
Groups "APE Project" group.
To post to this group, send email to
[email protected]
<mailto:[email protected]>
<mailto:ape-project@__googlegroups.com
<mailto:[email protected]>>
To unsubscribe from this group, send email to
ape-project+unsubscribe@__goog__legroups.com
<http://googlegroups.com>
<mailto:ape-project%[email protected]
<mailto:ape-project%[email protected]>__>
For more options, visit this group at
...
plus de détails »
