Hi,
OK. But how do you populate the table on the client side?
I see that the client gets the CHL from the server sendResponse, but
how do you know the CHL that each command used?
2011/11/16 Nathan Tran <[email protected]
<mailto:[email protected]>>
Nicolas,
sendResponse() sends the chl with the response for me. Note that
the chl won't be sent back on the CONNECT command. You can get
the CHL manually using infos.chl but I get 0 instead of 1 when I
get a response from the CONNECT command. Subsequent commands will
have the correct CHL returned upon getting a response from
sendResponse function.
Nathan.
On Tue Nov 15 17:14:58 2011, Nicolas wrote:
OK. But how do you get the challenge that the command was
associated
to? request.send does not return this information, does it?
That's the
missing piece in the puzzle for me.
On 15 nov, 23:55, Nathan Tran<[email protected]
<mailto:[email protected]>> wrote:
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]>
<mailto:[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<ioa.guib...@__googlemail.com
<mailto:[email protected]>
<mailto:ioa.guib...@__googlemail.com
<mailto:[email protected]>>
<mailto:ioa.guibert@
<mailto:ioa.guibert@>__googlema__il.com
<http://googlemail.com>
<mailto:ioa.guib...@__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]>>
<mailto:[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:[email protected]
<mailto:[email protected]>>
<mailto:christophermarkdod...@
<mailto:christophermarkdod...@>____googlemail.com
<http://googlemail.com>
<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://googlema__il.com>
<http://googlemail.com>
<mailto:ioa.guib...@
<mailto: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]>>
<mailto:ape-project@
<mailto:ape-project@>__googlegr__oups.com
<http://googlegroups.com>
<mailto:ape-project@__googlegroups.com
<mailto:[email protected]>>>
To unsubscribe from this group, send
email to
ape-project+unsubscribe@__goog____legroups.com
<http://goog__legroups.com>
<http://googlegroups.com>
<mailto:ape-project%[email protected]
<mailto:ape-project%[email protected]>
<mailto:ape-project%__252Bunsubscribe@googlegroups.__com
<mailto:ape-project%[email protected]>>__>
For more options, visit this group at
...
plus de détails »
--
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]>
To unsubscribe from this group, send email to
ape-project+unsubscribe@__googlegroups.com
<mailto:ape-project%[email protected]>
For more options, visit this group at
http://groups.google.com/__group/ape-project?hl=en
<http://groups.google.com/group/ape-project?hl=en>
---
APE Project (Ajax Push Engine)
Official website : http://www.ape-project.org/
Git Hub : http://github.com/APE-Project/
--
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]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/ape-project?hl=en
---
APE Project (Ajax Push Engine)
Official website : http://www.ape-project.org/
Git Hub : http://github.com/APE-Project/
