On 12/24/06, class acts <[EMAIL PROTECTED]> wrote:
On 12/24/06, Vinod Panicker <[EMAIL PROTECTED]> wrote:
> On 12/24/06, class acts <[EMAIL PROTECTED]> wrote:
> > Hi All,
> >
> > It seems that using filter_compression on the server side and
> > jzlib's Z_PARTIAL_FLUSH on the client side that packets are buffered
> > in either direction. I have tried not using BufferedOutputstream,
> > tried flushing, etc.. but sometimes it will do that. I believe that
> > it is party of the PARTIAL_FLUSH mechanism anyway. Are there any
> > other streaming compression options available or does anyone know of a
> > way to force it to send the envelope out the wire? If anyone has had
> > different experience I would be interested in knowing.
>
> Do you mean to say that the packets that your client and server are
> writing are not being sent immediately over the wire?
>
> If so, then I don't see this as an issue with the compression filter
> or JZlib's Z_PARTIAL_FLUSH mechanism. Make sure that you have set
> TCP_NO_DELAY to true for your sockets and then let us know.
>
> Regards,
> Vinod.
>
Hi thanks for the reply. I have an echo server implemented using
plaintext, ssl and jzlib. It works perfectly with plaintext and ssl
but as soon as I enable jzlib on either it delays some packets. I
think it's because of the partial_flush mechanism - it has to buffer
sometimes to build a block of data perhaps. I have tried every socket
option in pretty much all logical combinations and it still delays the
write sometimes. keep in mind my packets sizes are around 7 bytes, im
sure if i were sending chunks of 4K then it would do it right away.
I'm sure that its not jzlib, since the partial flush mechanism is
there because there are NO blocks of data to be made - its a stream
that is being compressed. The compression header is just sent once at
the beginning and whatever data is compressed, is immediately
available. To verify that the compression filter is not the culprit,
just use log messages in the filter chain and verify for yourself.
This seems to me an issue with TCP_NO_DELAY. If you can provide a test
program, we could run it and verify if there's an issue.
Regards,
Vinod.
