[Help-smalltalk] Re: [feature] Performance degradation in TCP.Socket (feature request setsockopt for TCP_NODELAY)

[Robin Redeker]

Issue status update for 
http://smalltalk.gnu.org/project/issue/119
Post a follow up: 
http://smalltalk.gnu.org/project/comments/add/119

Project:      GNU Smalltalk
Version:      <none>
Component:    Bindings (other)
Category:     feature requests
Priority:     normal
Assigned to:  bonzinip
Reported by:  elmex
Updated by:   elmex
Status:       patch

> Yes, an alternative could be a patch that makes #flush not use
> TCP_NODELAY, and adds #flushToNetwork which uses it

Yes, thats sounds ok to me.

> My reasoning was that when #flush is used, either you *want*
> TCP_NODELAY behavior (low latency) or you are not going to write any
> data soon to the socket because you're waiting for a reply.  In the
> latter case, Nagle's algorithm is not going to be useful and the
packet
> will be sent anyway (only incurring a delay).

Hmm, #flush was for me: "flush buffers to the OS", and then don't care
what the OS does with the data. TCP_NODELAY would only tell the OS how
to deal with
data it received from the application.

> In fact, with the kind of high-level buffering that gst performs on
> sockets, Nagle's algorithm may even be completely useless...
> > Do you agree?

Hmm, I guess I agree mostly. I only wonder whether there are cases of
calling

   * flush when it does not mean 'flush down to network'.




My suggestion to make it optional was merely because I'm not sure of
the
impact on everyday socket usage. It's just that TCP_NODELAY is not
enabled
by default for sockets for a good reason.

If you think there is no problem with no-delay-flush by default in gst
and
that it fits into the way gst does socket stuff, then I don't object to
enabling
it by default.