[erlang-questions] gen_tcp nonblocking send

Per Hedeland <>
Thu May 1 12:20:47 CEST 2008

Daniel Ginsburg <> wrote:
>What I have is a protocol which basically sends {key, value} over TCP 
>connection. Set of keys is large but limited. Receiver is not really 
>interested to hear all the changes of value for a particular key, it 
>just wants to know the most recent values for a key. It is also very 
>important to communicate changes of value for any key as fast as possible.
>In case when receiver is able to cope with the load, the best tactic is 
>to send all the changes as soon as they occur. But when receiver is 
>overloaded (or there's network congestion), there's important 
>optimization. If we have {k1, val1} sitting in queue and there's another 
>update for that key, we can, instead of adding it to the queue, simply 
>replace {k1, val1} with {k1, val2}. Thus saving network resources and 
>reducing load on receiver. In order to do that, I need to keep my own 
>queue and I need a way to know when it is safe to start dequeuing pairs 
>and send them to the socket.

I think this fits a common Erlang solution: "use another process".
I.e. have a separate "sender" process that just does the potentially
blocking gen_tcp:send(), ack'ing back to the "real" sender when it
returns. The "real", intelligent sender will send messages to this
process instead of calling gen_tcp:send() directly, and when it has sent
a message and not yet received the corresponding ack, it must go into
"intelligent queuing mode", where it buffers updates and eliminates
obsoleted ones. Implementing this in Erlang is simpler than describing

--Per Hedeland

More information about the erlang-questions mailing list