> > That may be overkill, but you could also "scramble" it by xoring it
> > with a randomly generated sequence (and send the seed to the
> > client to allow him to reproduce the sequence). The only overhead
> > would thus be the seed.
> > By the way, that could be applied to any message, not necess
On 10/19/2011 01:42 PM, Frédéric Grelot wrote:
That seems like a good idea.
Note that if the first image is not compressed, we may have a similar
problem
with WAN accelerators. Also maybe it is better to always compress it.
This random buffer was intended as a quick fix.
In the long run, we woul
> That seems like a good idea.
> Note that if the first image is not compressed, we may have a similar
> problem
> with WAN accelerators. Also maybe it is better to always compress it.
>
> This random buffer was intended as a quick fix.
> In the long run, we would like to measure network statisti
On 10/18/2011 11:50 PM, Yaniv Kaul wrote:
On 18/10/2011 19:20, Uri Lublin wrote:
WAN accelerators may compress the zeros which results with a
wrong bandwidth calculation.
Is this really the right approach? Why not calculate the latency based on the
time it takes to send the first image?
That i
On Tue, Oct 18, 2011 at 11:50:37PM +0200, Yaniv Kaul wrote:
> On 18/10/2011 19:20, Uri Lublin wrote:
> >WAN accelerators may compress the zeros which results with a
> >wrong bandwidth calculation.
>
> Is this really the right approach? Why not calculate the latency
> based on the time it takes to
On Tue, Oct 18, 2011 at 11:50:37PM +0200, Yaniv Kaul wrote:
> On 18/10/2011 19:20, Uri Lublin wrote:
> >WAN accelerators may compress the zeros which results with a
> >wrong bandwidth calculation.
>
> Is this really the right approach? Why not calculate the latency
> based on the time it takes to
On 18/10/2011 19:20, Uri Lublin wrote:
WAN accelerators may compress the zeros which results with a
wrong bandwidth calculation.
Is this really the right approach? Why not calculate the latency based
on the time it takes to send the first image?
That image is not using the WAN feature anyway,
On Tue, Oct 18, 2011 at 07:20:15PM +0200, Uri Lublin wrote:
> WAN accelerators may compress the zeros which results with a
> wrong bandwidth calculation.
>
ACK with some nitpicks on whitespace.
I was hoping we will throw this stuff away, but I guess it's still
there..
> The buffer is initialize
WAN accelerators may compress the zeros which results with a
wrong bandwidth calculation.
The buffer is initialized once.
---
server/main_channel.c | 32
1 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/server/main_channel.c b/server/main_channel.
