I am not sure what is causing these delays, if you could narrow it down to which method in the client library it is in during the delay that would be useful, the default request timeout is 5 seconds, I am not sure if the delay is just a multiple of this (i..e several requests being attempted?) you could try reducing the request timeout and see if that helps...

Toby

2009/1/7 Elvina Motard <elvina.motard@spaceapplications.com>
Hi,

Thank you very much for the fix. It works; but there is still a weird
issue: after the reconnection, it takes a lot of time to get the sensor
data on my callbacks: about 30 seconds (or even more) ! Then the
callbacks are called normally and it works fine, but this delay looks
strange to me...

Elvina


Toby Collett wrote:
> Can you try out the fix I added to the bug report and see if that
> corrects the problem...
>
> https://sourceforge.net/tracker2/index.php?func=detail&aid=2483176&group_id=42445&atid=433164
> <https://sourceforge.net/tracker2/index.php?func=detail&aid=2483176&group_id=42445&atid=433164>
>
> Toby
>
> 2009/1/6 Elvina Motard <elvina.motard@spaceapplications.com
> <mailto:elvina.motard@spaceapplications.com>>
>
>     Thanks for the help. I have actually tried Peter's solution, but it
>     doesn't change anything in my case. I think you made a mistake in the
>     pseudo code :
>     if((peek = playerc_client_internal_peek(client,10)) < 0)
>     return -1;
>     else if(peek == 0)
>     - continue;
>     + {
>     + peek0ctr = peek0ctr+1;
>     + if (peek0ctr >= 100)
>     + {
>     + return -1;
>     + }
>     + else
>     + continue;
>     + }
>     + peek0ctr = 0;
>     should peek0ctr be reseted there ? I don't think so, otherwise it
>     never
>     notices the disconnection because peek0ctr is never increased...
>
>     Even with this modification, it doesn't change anything...
>     Any suggestions ?
>
>     I also have another question regarding the multi-threading with
>     player.
>     I use the StartThread method of PlayerClient to start the thread which
>     will pass into the methods I have assigned to the signals
>     callback; but
>     then I am not able to catch the exceptions happening in this
>     thread. How
>     can I do that ?
>
>     Thanks for your help,
>
>     Elvina
>
>
>     Toby Collett wrote:
>     > I have created a bug for this
>     >
>     >
>     https://sourceforge.net/tracker2/?func=detail&aid=2483176&group_id=42445&atid=433164
>     <https://sourceforge.net/tracker2/?func=detail&aid=2483176&group_id=42445&atid=433164>
>     >
>     <https://sourceforge.net/tracker2/?func=detail&aid=2483176&group_id=42445&atid=433164
>     <https://sourceforge.net/tracker2/?func=detail&aid=2483176&group_id=42445&atid=433164>>
>     >
>     > Toby
>     >
>     > 2008/12/15 Peter Nordin <Peter.Nordin@liu.se
>     <mailto:Peter.Nordin@liu.se> <mailto:Peter.Nordin@liu.se
>     <mailto:Peter.Nordin@liu.se>>>
>     >
>     >     Hello
>     >
>     >     I recently had similar problems. I am trying to communicate
>     over wlan
>     >     between to computers but when the range is to large, or if
>     the wlan
>     >     fails the player servers will crash. (The player read
>     functions throws
>     >     an exception). Anyway I tried using the threaded read with boost
>     >     but was
>     >     unable to make it work. Instead I am using try catch on my
>     read in
>     >     order
>     >     to capture the failed read and handle the situation in some way.
>     >     Anyway
>     >     to make a long boring story a bit shorter, I found something
>     >     strange in
>     >     client.c that might be relevant for your problem. The
>     playerclient
>     >     uses
>     >     pull-mode as default apparently. And in the code after the
>     >     "pull-request" has been sent there is a while loop that peak
>     onto the
>     >     socket to see if data has arrived. If no data is found the
>     peek times
>     >     out after 10ms and returns 0. If 0 is returned the while loop
>     >     restarts.
>     >     If not, a time variable is decreased and data is read. The
>     problem is
>     >     that when no data is received the peek will always return 0 and
>     >     the loop
>     >     will never end. For me this occurs if the two computers are
>     to far
>     >     away
>     >     from each other so that the pull request does not reach the
>     other
>     >     computer.
>     >
>     >     The problem is near row 770 in client.c. Bellow is the original
>     >     code and
>     >     later my "fixed version"
>     >     To work around this I added a counter that counts to 100 (hard
>     >     coded) =
>     >     1 second timeout and then returns -1 if no data is received.
>     This is a
>     >     crude "fix" but I was in a hurry. I don't know if this will help
>     >     at all
>     >     but maybe it could be useful. I really should report this in
>     the bug
>     >     tracker, I might do that later today if I have time. If
>     anyone has any
>     >     opinions about this please let me know. Maybe I have completely
>     >     misunderstood something.
>     >
>     >     /Peter Nordin
>     >
>     >     Original:
>     >
>     >     // Read packets until we get a reply. Data packets get queued up
>     >     // for later processing.
>     >     while(t >= 0)
>     >     {
>     >     gettimeofday(&last,NULL);
>     >
>     >     // Peek at the socket
>     >     if((peek = playerc_client_internal_peek(client,10)) < 0)
>     >     return -1;
>     >     else if(peek == 0)
>     >     continue;
>     >     // There's data on the socket, so read a packet (blocking).
>     >     if(playerc_client_readpacket(client, &rep_header,
>     client->data) < 0)
>     >
>     >     "Fixed": (Note the + and signs for new and removed rows of
>     code)
>     >
>     >     // Read packets until we get a reply. Data packets get queued up
>     >     // for later processing.
>     >     + peek0ctr = 0;
>     >     while(t >= 0)
>     >     {
>     >     gettimeofday(&last,NULL);
>     >
>     >     // Peek at the socket
>     >     if((peek = playerc_client_internal_peek(client,10)) < 0)
>     >     return -1;
>     >     else if(peek == 0)
>     >     - continue;
>     >     + {
>     >     + peek0ctr = peek0ctr+1;
>     >     + if (peek0ctr >= 100)
>     >     + {
>     >     + return -1;
>     >     + }
>     >     + else
>     >     + continue;
>     >     + }
>     >     + peek0ctr = 0;
>     >
>     >     // There's data on the socket, so read a packet (blocking).
>     >     if(playerc_client_readpacket(client, &rep_header,
>     client->data) < 0)
>     >
>     >
>     >     Elvina Motard wrote:
>     >     > Dear all,
>     >     >
>     >     > I have been facing a problem for quite a while, and I didn't
>     >     find any
>     >     > way to solve it.
>     >     > I am using the player 2.1.1 release which features signals and
>     >     threads
>     >     > inherited from the boost library, which is a library that I am
>     >     used to.
>     >     > In my application, I connect to a (stage) robot, set the retry
>     >     limit to
>     >     > infinity, I set up signals to go to read the different proxies
>     >     and then
>     >     > I start the robot thread (PlayerClient::StartThread).
>     >     > Then I stop the stage simulation and it tries to
>     reconnect. When I
>     >     > launch stage again, on my client console, a player comment is
>     >     written
>     >     > saying that I successfully reconnected to the robot, but
>     then I
>     >     never
>     >     > get anything on my signals callbacks.
>     >     > I first thought that it is a signal program, and that the
>     >     signals are
>     >     > not reconnected upon reconnection of the robot, but when I
>     >     inspect the
>     >     > backtrace of player, I see that it is blocked into the Read
>     >     method of
>     >     > the PlayerClient...
>     >     >
>     >     > I would like to know how this is supposed to work; if in the
>     >     > implementation the signals are still connected after a
>     >     deconnection; if
>     >     > other people are facing this problem...
>     >     >
>     >     > Thanks,
>     >     >
>     >     > Elvina
>     >     >
>     >     >
>     >     >
>     >
>     ------------------------------------------------------------------------------
>     >     > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las
>     >     Vegas, Nevada.
>     >     > The future of the web can't happen without you.  Join us at
>     >     MIX09 to help
>     >     > pave the way to the Next Web now. Learn more and register at
>     >     >
>     >
>     http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
>     >     > _______________________________________________
>     >     > Playerstage-developers mailing list
>     >     > Playerstage-developers@lists.sourceforge.net
>     <mailto:Playerstage-developers@lists.sourceforge.net>
>     >     <mailto:Playerstage-developers@lists.sourceforge.net
>     <mailto:Playerstage-developers@lists.sourceforge.net>>
>     >     >
>     https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>     >     >
>     >
>     >
>     >
>     ------------------------------------------------------------------------------
>     >     SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las
>     >     Vegas, Nevada.
>     >     The future of the web can't happen without you.  Join us at
>     MIX09
>     >     to help
>     >     pave the way to the Next Web now. Learn more and register at
>     >
>     http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
>     >     _______________________________________________
>     >     Playerstage-developers mailing list
>     >     Playerstage-developers@lists.sourceforge.net
>     <mailto:Playerstage-developers@lists.sourceforge.net>
>     >     <mailto:Playerstage-developers@lists.sourceforge.net
>     <mailto:Playerstage-developers@lists.sourceforge.net>>
>     >
>     https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>     >
>     >
>     >
>     >
>     > --
>     > This email is intended for the addressee only and may contain
>     > privileged and/or confidential information
>     >
>     ------------------------------------------------------------------------
>     >
>     >
>     ------------------------------------------------------------------------------
>     >
>     >
>     ------------------------------------------------------------------------
>     >
>     > _______________________________________________
>     > Playerstage-developers mailing list
>     > Playerstage-developers@lists.sourceforge.net
>     Elvina Motard
>     Robotics Engineer
>
>     Space Applications Services
>     Leuvensesteenweg 325, B-1932 Zaventem, Belgium
>     Tel: +32 2 721 54 84 Fax: +32 2 721 54 44
>     URL: http://www.spaceapplications.com
>
>
>     ------------------------------------------------------------------------------
>     _______________________________________________
>     Playerstage-developers mailing list
>     Playerstage-developers@lists.sourceforge.net
>     <mailto:Playerstage-developers@lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>
>
>
>
> --
> This email is intended for the addressee only and may contain
> privileged and/or confidential information
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Playerstage-developers mailing list
> Playerstage-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>


--
Elvina Motard
Robotics Engineer

Space Applications Services
Leuvensesteenweg 325, B-1932 Zaventem, Belgium
Tel: +32 2 721 54 84 Fax: +32 2 721 54 44
URL: http://www.spaceapplications.com


------------------------------------------------------------------------------
_______________________________________________
Playerstage-developers mailing list
Playerstage-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/playerstage-developers



--
This email is intended for the addressee only and may contain privileged and/or confidential information