Hi,
the Scheduler is on server side,
fetch_msg should returns the message that the server want to send to the
client.
I think it should be faster than using a session to do communication
from server to client and the latency will be better.
The communication from server to client at the server initiative is less
efficient because the protocol http asymetric, a server can only answer
a request.
For this purpose, the client has to maintain a ping request on the
server, and from time to time no ping request is available on server.
For instance, just after sending a message from client to server, you
need to wait that the client receives the message and do a new ping
request again before a message can be sended again from the server to
the client.
On 30/12/2011 16:49, Thomas Recouvreux wrote:
> I don't understand some parts of your code,
>> the Scheduler is on client side or server side ?
> fetch_msg() fetch the client message or the server one ? (server one
> if I have well understand your explanations)
> where do you use the 'msg' argument ?
>> Do you think your way is faster than the way I am using ? because I
> made the calls non blocking using @async, and I don't really care if
> sometime, somethings are executed in the wrong order, it will be
> invisible.
>> 2011/12/30 Polux Moon <polux.moon at gmail.com <mailto:polux.moon at gmail.com>>
>> Scheduler.push is here to push the client message processing at
> the end of the todo list of the scheduler.
> It will be executed later so the call returns immediately.
>>> The client will wait for the server to answer, that's why all code
> inside the proccess_client_msg_and_return_server_msg should be
> fast and non blocking.
> The server have to do minimal processing, i.e. just push the thing
> to do later and send back the server message that should be
> already computed or with minimal computing and absolutely no
> blocking operations (no session or network involved).
>> The drawback of the approach is that the server will always be in
> full load, messages will always be exchanged at maximal
> server/client rate even if nothing happens in the game.
>>> On Fri, Dec 30, 2011 at 4:08 PM, Thomas Recouvreux
> <thomas.recouvreux at gmail.com <mailto:thomas.recouvreux at gmail.com>>
> wrote:
>> Hi,
>> I am expecting a real time processing. So I am interesting in
> both I guess.
>> Can you tell me more about Scheduler.push ?? There is a stack
> and when I push the Scheduler try to pop and execute as fast
> as possible ?
> I tried you solution, the problem is that I have to wait the
> answer and it can be long, and I don't know why, but I have
> the impression the call blocks all javascripts process (I have
> a loop that refresh the screen).
>> So here is the process I use for the moment :
> timer on each client side, calling a @async at publish function
> to send to the server the position of the player, wich is
> stored in a DB
> timer on server side, calling a Network.broadcast to
> synchronize all clients (sending informations of the db)
>>> 2011/12/30 Polux Moon <polux.moon at gmail.com> <mailto:polux.moon at gmail.com>>
>> Hi,
>> Are you expecting some real time processing based on your
> timings constraints ?
> Are you interested in the rate (e.g. fluidity of
> animation) or in the latency (e.g. real-time interaction)
> or both ?
>>> First you should know that the latency is not the same in
> both direction (via Network or Session or remote function
> call). (see * )
>> Second, in a multi-client setup you should be careful
> about locks behaviour since they can increase latency and
> lower concurrency.
> Network guarantees the Network's state coherency by a
> locking mechanism.
>> * For sending a message to server to client you have to
> wait that a ping request of the client is available.
> The runtime ensures that such a ping request is available
> most of the time.
> Just after using such request on the server, the client is
> made aware of this, and send a new ping request.
> While this new request has not hit the server, all
> messages that the server want to send to the client are
> stored and send all together when the request hits the
> server.
> ==> Regeneration of the ping request on server side take
> a complete round trip. The rate can be kept high by
> sending many message at once.
>>>> As a first guess I would say that the fastest way to do
> this double communication is by emitting a request from
> client to server to pass 'client to server' message and
> use the answer of this request to pass 'server to client'
> message.
> This way you have a better latency and minimal message
> exchange.
>> It is easy to do ; you just need to define an 'exposed'
> server function (or @publish in classic syntax).
>> For instance:
>> type client_msg = ...
> type server_msg = ...
>> exposed
> function server_msg
> proccess_client_msg_and_return_server_msg(client_msg msg){
> Scheduler.push{ function()
> code to process the client message // could be your
> local network or any processing
> }
> returned_msg = fetch_msg()
> returned_msg
> }
>> If rate need to be higher, you can pass and return a list
> of message instead of only one message.
>> ps: I used features of the new syntax so you may need to
> adapt if you are not up to date.
>> On Thu, Dec 29, 2011 at 4:19 PM, Thomas Recouvreux
> <thomas.recouvreux at gmail.com> <mailto:thomas.recouvreux at gmail.com>> wrote:
>> Hi,
>> I would like to know what is the fastest way to send
> messages between client and server (in both directions).
> My aim is to make an exchange every 15ms.
> For the moment I use Network wich allow me to send
> message every 30ms without lagging on client side, but
> maybe there is something much faster ?
>> _______________________________________________
> Opa mailing list
>Opa at lists.owasp.org <mailto:Opa at lists.owasp.org>
>https://lists.owasp.org/mailman/listinfo/opa>>>>> _______________________________________________
> Opa mailing list
>Opa at lists.owasp.org <mailto:Opa at lists.owasp.org>
>https://lists.owasp.org/mailman/listinfo/opa>>>>>>> _______________________________________________
> Opa mailing list
>Opa at lists.owasp.org>https://lists.owasp.org/mailman/listinfo/opa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/opa/attachments/20120102/8ebea6ad/attachment-0001.html>