Third-party send to active and passive TCP sockets
Thu Oct 28 17:15:51 CEST 1999
Jim Larson <> wrote:
>Per Hedeland writes:
>>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.
Of course - I didn't mean to imply that you might just as well use
active mode *in general* - just that if your input process didn't do
anything in particular with the input, there wasn't much of an actual
So, I assume the input process behaves as above, with the addition that
the server can tell it to stop recv()ing when it considers the load too
high (based on some criteria). The question then becomes why the server
can't just do the recv()ing itself, and stop doing it when the load is
too high. I know you said that you don't want it to block, but if it's
just blocking when it's waiting for new input, that shouldn't be a
problem I think.
But of course it all depends on your overall design, e.g. whether the
server farms out the actual processing to other processes and then needs
to collect the results, etc. It also depends on whether there is any
inherent flow control in your application - you said it was an RPC
server, if the clients always wait for a response after sending a query,
and the number of clients isn't infinite, there's an upper limit to how
big your "work queue" can become.
More information about the erlang-questions