Third-party send to active and passive TCP sockets

[Jim Larson]

In message <199910261218.OAA27576@REDACTED>
Per Hedeland writes:
>Jim Larson <jim@REDACTED> wrote:
>>For what it's worth, I'm trying to implement a gen_server module
>>that implements the client-side logic of a popular RPC package,
>>using TCP as a transport protocol.  The data rates may be intense,
>>so to avoid running the socket open-loop, I'm trying to have
>>dedicated input and output processes to read from and write to
>>(respectively) the passive socket.  The parent process "P" above
>>is the server process, and should never block, thus shouldn't do
>>I/O with a passive socket directly.
>
>Hmm, if the input process is just going to turn around and do a
>'Server ! Packet' when the recv() returns, I think you might just as
>well (or better) use active mode with the server as controlling process
>- the input process is effectively an "activifier" anyway then.

With passive sockets, we have the option of deferring further
recv()s in response to high load.

For client-side sockets, we can acheive the same effect with active
sockets by delaying the send() of requests to limit the number of
outstanding requests at any one time.

For server-side sockets, we may be overwhelmed by client request
messages.  Any suggestions for what we can do here?

Does the Erlang process scheduler look at the depth of message
queues in order to avoid overflows?

Jim