Menu
▾
▴
Re: [Playerstage-developers] Reconnection problem in a multithreaded c++ client library
|
From: Elvina M. <elv...@sp...> - 2009-01-05 14:56:22
|
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>
>
> Toby
>
> 2008/12/15 Peter Nordin <Pet...@li... <mailto:Pet...@li...>>
>
> 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
> > Pla...@li...
> <mailto:Pla...@li...>
> > 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
> Pla...@li...
> <mailto:Pla...@li...>
> 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
> Pla...@li...
> 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
|