[Spread-users] Problem with Java client
rcaudy at gmail.com
Wed Aug 17 20:31:35 EDT 2005
My reason for considering TCP_NODELAY is to avoid holding onto data
longer than necessary, hopefully leaving the buffer empty when the
socket is closed. Regardless, I think it's an appropriate setting for
the Java API to use, the same as the C API.
>From the description of SO_LINGER read after reading Theo's response,
we should be using it in both the Java and C APIs. It seems like a
more correct way to solve Jaroslaw's problem, as well as a generally
good thing to use regardless, considering the kind of guarantees we're
trying to preserve.
On 8/17/05, Theo Schlossnagle <jesus at omniti.com> wrote:
> Ryan Caudy wrote:
> >It sounds to me like there's some sort of buffering going on in the
> >Java client at the socket level.
> >If I had to guess, I would say that this is because the Spread Java
> >API isn't using TCP_NODELAY. The C API is, and hence wouldn't be
> >subject to the same problem, assuming that my hypothesis is correct.
> >Attached to this message is a patch to SpreadConnection.java
> >(generated against the latest CSV version) which should set this
> >socket option.
> >Please let me know if this helps.
> TCP_NODELAY effect how the socket reacts when you send data on it. Not
> how it reacts when you close it.
> Look at setsockopt(.... SO_LINGER). and in C make sure you shutdown()
> the socket before you call close. (read the shutdown man page).
> If you just call close() on a socket, you can certainly loose data
> you've written to it that has yet to be transmitted.
> Best regards,
More information about the Spread-users