Push/Pull and player 2

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

Push/Pull and player 2

Toby Collett-3
Ive just commited a fairly major changeset to player provided by Geoff.
It is a little close to the planned release but the fixes/featres
provided are pretty much essential for slow update clients so it was
worth doing now.

Here is Geoff's description of the changes:
----------------------------------------------------------
On Friday we found a fairly major problem in the message queue system.
The replace rules system wasn't functioning for the queue of messages to
be sent to the client. Messages that should have been replaced by more
up to date ones were still being sent. The problem was caused by the
implementation of the message queue system and the TCP library.
Basically, when a message went into the queue, the TCP system would send
it out immediatly if there was room in the OS's buffer for the socket,
even if the client hadn't requested data. As a result, data packets
would end up being sent to the client, but not received, before the
client had requested data, even if the client had set a replace rule for
data packets. This means that if your client can't read fast enough to
remove data packets as fast as the server generates them then your
client will get increasingly out of date data each time it reads. There
are many places this could occur: if your program sits around waiting
for user input before continuing and you don't read in that time, or if
your data packet contains a 4MB image and takes a while to be received,
or if you have to do some heavy processing between two reads.

To fix this problem, we could have made all client programs read until
peek tells them there is nothing left waiting, but that makes client
programs more complex than they need to be, and if there is a lot of
data you may never catch up (plus it renders replace rules for messages
to the client useless). So we have reintroduced push and pull modes, but
in the same way as before. This is how it all works now:
PUSH mode makes the server function as it did before you updated from
CVS today. Data packets are pushed into the message queue, and then sent
out from there to the OS's buffer when the TCP library gets to them. You
will get all data sent by the server, but it's up to the client to deal
with the fact that it could be significantly out of date.
PULL mode means that no data will leave the message queue until it is
marked as ready to be sent. When the client makes a data request, the
server marks all messages currently in the queue as ready to be sent and
adds a sync packet at the end of them (note that sync does not mean the
same thing it used to; it now means the end of request data, not a 10Hz
clock tick). Only data messages need to be marked, all other message
types are marked as ready as soon as they enter the queue and so will
get sent as soon as possible. The client library, when in pull mode,
will keep reading packets until it receives the sync. The data request
is made automatically at the start of the client's read function. The
usual way to use pull mode is to set a replace rule from the client that
replaces all data packets. Then the client can get the most up to date
data possible because replace rules will catch messages before they
leave the queue.
Currently push is the default mode, so everything will operate as it did
before. In most cases, however, you would probably want to be in pull
mode to ensure your sensor data is up to date.

Geoff
----------------------------------------------------

If anyone running CVS has a chance to update and confirm that player
still behaves itself that would be great, we have tested it ourselves
and it seems fine (and it has solved the problem of out of date data)

Toby


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Playerstage-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/playerstage-developers
Reply | Threaded
Open this post in threaded view
|

position interface

Brad Kratochvil
Hey all,

Among other things, I'm going through some of the interface stuff and I
noticed that there are still some references to the deprectated
"position" interface in files such as player.h and interface_util.cc.

Do we still need those, or are they there for backward compatibility?

Cheers,

-bk


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Playerstage-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/playerstage-developers
Reply | Threaded
Open this post in threaded view
|

Re: position interface

Toby Collett-3
My vote is to remove it, Player2 is similar but not directly compatable
with player 1.x and so we may as well not worry about compatability in
this respect and make the most of our chance to clean things up.

Toby

Brad Kratochvil wrote:

> Hey all,
>
> Among other things, I'm going through some of the interface stuff and I
> noticed that there are still some references to the deprectated
> "position" interface in files such as player.h and interface_util.cc.
>
> Do we still need those, or are they there for backward compatibility?
>
> Cheers,
>
> -bk
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Playerstage-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Playerstage-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/playerstage-developers
Reply | Threaded
Open this post in threaded view
|

Re: position interface

Brian Gerkey

On Feb 26, 2006, at 11:29 AM, Toby Collett wrote:

> My vote is to remove it, Player2 is similar but not directly  
> compatable with player 1.x and so we may as well not worry about  
> compatability in this respect and make the most of our chance to  
> clean things up.

Agreed.

        brian.

>
> Toby
>
> Brad Kratochvil wrote:
>> Hey all,
>> Among other things, I'm going through some of the interface stuff  
>> and I
>> noticed that there are still some references to the deprectated
>> "position" interface in files such as player.h and interface_util.cc.
>> Do we still need those, or are they there for backward compatibility?
>> Cheers,
>> -bk
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
>> language
>> that extends applications into web and mobile media. Attend the  
>> live webcast
>> and join the prime developer group breaking into this new coding  
>> territory!
>> http://sel.as-us.falkag.net/sel?
>> cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> Playerstage-developers mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the  
> live webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel?
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Playerstage-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Playerstage-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/playerstage-developers