Fix Buffering Issue

[gajan]

Add a fixed width buffer on the client and the server side.

Sync the header with the binary blob? (@Sathe: Not sure if we were planing this for this week. Please update)

[dhananjaysathe]

Not too sure will need to work this out with Dominique

Agree. Talk to Dominique and come up with a plan. This is your top priority. Groovy support can wait.

[dhananjaysathe]

Buffer now non polling and queued.
72820b1
empty buffer corner case fix:
53efcb8

Have a look .Any comments suggestions welcome , needs testing , with rosbag or Vlad

[gajan]

Do it with rosbag

G

On Tue, May 14, 2013 at 6:08 PM, Dhananjay Sathe
notifications@github.comwrote:

Buffer now non polling and queued.
72820b172820b1
empty buffer corner case fix:
53efcb853efcb8

Have a look .Any comments suggestions welcome , needs testing , with
rosbag or Vlad

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-17886425
.

[dhananjaysathe]

Not really. I need robot :-D the wifi and robo are the bottle necks. Rodbag
not really useful

• Sent from my Android Mobile Device. Pardon the brevity.
  On May 14, 2013 6:41 PM, "Gajamohan Mohanarajah" notifications@github.com
  wrote:

Do it with rosbag

G

On Tue, May 14, 2013 at 6:08 PM, Dhananjay Sathe
notifications@github.comwrote:

Buffer now non polling and queued.
72820b1<
72820b13665dff204bef4ed7f9112b950d9e3949>

empty buffer corner case fix:
53efcb8<
53efcb8a16e8edb6de3466388f71833b0a45f33f>

Have a look .Any comments suggestions welcome , needs testing , with
rosbag or Vlad

—
Reply to this email directly or view it on GitHub<
https://github.com/IDSCETHZurich/rce/issues/8#issuecomment-17886425>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-17888583
.

[gajan]

Since Vlad is busy having PCL on board this is not an option.

2 options:

1. using --rate option you can playback a rosbag in higher rates
   http://www.ros.org/wiki/rosbag/Commandline#play
2. We have extra boards, wireless dongles, and power supplies for the
   board. Try it with them.

G

On Tue, May 14, 2013 at 6:56 PM, Dhananjay Sathe
notifications@github.com wrote:

Not really. I need robot :-D the wifi and robo are the bottle necks.
Rodbag
not really useful

• Sent from my Android Mobile Device. Pardon the brevity.
  On May 14, 2013 6:41 PM, "Gajamohan Mohanarajah"
  notifications@github.com
  wrote:

Do it with rosbag

G

On Tue, May 14, 2013 at 6:08 PM, Dhananjay Sathe
notifications@github.comwrote:

Buffer now non polling and queued.
72820b1<

72820b13665dff204bef4ed7f9112b950d9e3949>

empty buffer corner case fix:
53efcb8<

53efcb8a16e8edb6de3466388f71833b0a45f33f>

Have a look .Any comments suggestions welcome , needs testing , with
rosbag or Vlad

—
Reply to this email directly or view it on GitHub<
https://github.com/IDSCETHZurich/rce/issues/8#issuecomment-17886425>
.

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/8#issuecomment-17888583
.

—
Reply to this email directly or view it on GitHub.

[mayanks43]

I think what we need to test is - bloating up of rce-ros client. I'll test it with rosbag.

[gajan]

Exactly! - G

On Wed, May 15, 2013 at 12:19 PM, Mayank Singh notifications@github.comwrote:

I think what we need to test is - bloating up of rce-ros client. I'll test
it with rosbag.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-17930590
.

[dhananjaysathe]

Implementation fix 2e1c21a should have always been push producers , this is what we are doing , it is a producer spewing output not generating on request.

[mayanks43]

Depends on your code design. Pullproducer was fitting in the earlier design. Pushproducer suits your current design.

[dhananjaysathe]

Although a Push Provider does seem to fit the case for designing the buffer it does not shut down on its own , the responsibility of shutting of the transport is now with the buffer and we would have to manually shut transports and deal with the ugly behavior.
A pull producer is shut from the transport side implicitly by twisted (it deals with the rest of ugly the closing bits on it's own) the first run Flag ensures the behavior desired and shut , I do not know if it will work the next time, perhaps new connections required in which case it will be recreated. This a reason not to reuse buffers on reconnect , also I don't know how practical that is as the binary data (mostly used in these case is high frequency in the first place to require a buffering implementation ) is probably made redundant in that time taken to reconnect.