[erlang-questions] gen_tcp/inet/flow control/misc

[Florian Zumbiehl]

Hi,

sorry, somehow your mail didn't end up in any of my mail folders, and I
only now discovered it in the mailing list's web archive ...

[...]
> After command 32, the window was full. Same for 33. I then turned on
> the receiver again and ran 34. The receiver got all the data from
> 30--34. Erlang must be buffering it. I'm not curious enough to know
> where exactly.

Thanks so far, that made things quite a bit clearer :-)

[...]
> >    So, the question basically condenses down to: What buffers are
> >    there in between the fd and the gen_tcp API, once again, and
> >    how do they interact with the various options? 
> 
> I think there's only really one. If you don't use send_delay, it's
> conceptually not there.

... unless there is a send_timeout specified and the socket doesn't
accept all the data before the timeout expires, in which case
there actually seems to be a buffer, probably just as unlimited as
the send_delay one? That's what I would conclude from your explanation.

> > And how would I implement flow control at the write side?
> 
> Avoid the problem: use a protocol with flow control.
> 
> The engineer's solution: use {send_timeout, N} and resign yourself to
>    not being able to know when a blocked socket becomes unblocked, at least 
>    not without sending it more data.
> 
> The "pure Erlang" solution: don't use {send_timeout, N}. Instead, use
>    multiple (Erlang) processes to keep track of whether the socket is 
>    blocked or not.

As far as that question is concerned, I was actually only looking for a
way to "sense the backpressure" in order to be able to propagate it
through the system to some external data source. For that purpose,
the blocking of gen_tcp:send without a send_timeout would probably do
in many (most?) cases.

What's missing, then, is the mechanism for actually propagating the
information through a pipeline of erlang processes, without making
them all work synchronously - which the "use a protocol with flow
control" would probably imply!?

> (I know, you asked more questions. Maybe someone else can pick up 
> where I left off, otherwise, maybe next week. Or read the source and
> experiment.)

Maybe ... now? ;-)

Florian