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.
