[erlang-questions] Wondering on active TCP socket

Tony Rogvall tony@REDACTED
Fri Aug 13 14:49:42 CEST 2010


{active, once}

/Tony

On 13 aug 2010, at 12.12, Kresten Krab Thorup wrote:

> Hi,
> 
> In "active" mode, a socket acts like an infinite loop that simply forwards incoming data to the designated target process.  Incoming data is repackaged according to the socket's current packet mode.
> 
> There is no flow control, unlike normal message sends where the sender is punished with reductions proportional to the size of the message queue.  The port driver does not have a concept of reductions that will slow it down, and most of it's operations run in the asynch threads that are independent of the normal scheduling of Erlang processes; so driver's are at liberty to run infinitely.
> 
> So perhaps you can insert something like this in your consume loop to do your own pseudo flow control - this will  switch active on/off according to some high/low watermark for the consuming process queue length.  But since the port runs independently, there is no guarantee that the queue does not overrun.
> 
> Kresten
> 
> 
> init() ->
>   Socket = inets:accept(...);
>   ControlState = set_controlled_active(Socket, 100, 200),
>   main_loop(ControlState).
> 
> main_loop(CS) ->
>     CS2 = control_active(true, CS),
>     receive 
>        {data, DataPkt} -> ...
>            main_loop(CS2)
>        ...
> 
> 
> %%%%%%%%%%%%%%%%%%%%%%%
> %% pseudo flow control for active sockets %%
> 
> -record(flow_control,{socket,is_active,low,high}).
> 
> 
> set_controlled_active(Socket, LowWaterMark, HighWaterMark) ->
>    [{active, IsActive}] = inet:getopts(Socket, [active]),
>    control_active(true,  
> 		   #flow_control { socket=Socket,
> 				   is_active=IsActive, 
> 				   low=LowWaterMark, 
> 				   high=HighWaterMark}).
> 
> 
> 
> %% you want it to be active, and it is currently set to active; test
> %% if our queue size is above the high watermark
> control_active(true, #flow_control{is_active=true, high=HW}=State) -> 
>    {message_queue_len, QLen} = erlang:process_info(message_queue_len),
>    case QLen > HW of 
> 	true -> 
> 	    ok = inet:setopts(State#flow_control.socket, [{active, false}]),
> 	    State#flow_control{is_active=false};
> 	false ->
> 	    State
>    end;
> 
> %% you want it to be active, but it is currently set to non-active; test
> %% if our queue size is below the LowWatermark
> control_active(true, #flow_control{is_active=false, low=LW}=State) -> 
>    {message_queue_len, QLen} = erlang:process_info(message_queue_len),
>    case QLen < LW of
> 	true ->
> 	    ok = inet:setopts(State#flow_control.socket, [{active, true}]),
> 	    State#flow_control{is_active=true};
> 	false ->
> 	    State
>    end;
> 
> %% setting active to false
> control_active(false, #flow_control{socket=Socket}=State ) -> 
>    ok = inet:setopts(Socket,[{active, false}]),
>    State#flow_control{is_active=false}.
> 
> 
> 
> On Aug 12, 2010, at 15:51 , Kaiduan Xie wrote:
> 
>> Hi, all,
>> 
>> From Joe's book,
>> 
>> "Once an active socket has been created, the controlling process will
>> be sent {tcp, Socket, Data} messages as data is received. There
>> is no way the controlling process can control the flow of these
>> messages. A rogue client could send thousands of messages to
>> the system, and these would all be sent to the controlling process.
>> The controlling process cannot stop this flow of messages."
>> 
>> "This process cannot control the flow of messages to the server loop.
>> If the client produces data faster than the server can consume this
>> data,
>> then the system can be flooded with messages—the message buffers will
>> fill up, and the system might crash or behave strangely."
>> 
>> For this case, I think that the flow control of underlying OS TCP
>> stack will kick in, and the sender can not send more packets. How the
>> system can be flooded with messages in erlang?
>> 
>> Can someone elaborate more on this point?
>> 
>> Thanks,
>> 
>> Kaiduan
>> 
>> ________________________________________________________________
>> erlang-questions (at) erlang.org mailing list.
>> See http://www.erlang.org/faq.html
>> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>> 
> 
> Kresten Krab Thorup, CTO, Trifork
> 
> 
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
> 



More information about the erlang-questions mailing list