Questions regarding TCP sockets

[Bengt Kleberg]

> I currently have an active TCP socket which is getting swamped by bursts
> of short messages sent by the other end resulting in processor overload.
> I would like to introduce flow control to prevent incoming bursts of
> data, for which, I understand that I need to change the socket to a
> passive mode. 
> 
> But I am not sure how to implement the receipt of packets from the
> socket. More precisely  - what is the difference between an active and
> passive socket? How does a passive socket introduce flow control? 

According to the kernel reference manual pages (gen_tcp) at erlang.org:
"
Packets sent from the peer will be delivered as messages
       
   {tcp, Socket, Data}
"
and
"
recv(Socket, Length) -> {ok, Packet} | {error, Reason}

This function receives a packet from a socket in passive mode.
"

So, active sockets sends messages to the process that are recived with 
'receive', as any other message.
Passive sockets do not send messages, instead one has to call
gen_tcp:recv/2 (or 3) to get the data.

> What is the purpose of the length parameter in the function call  
> 
> 	gen_tcp:recv(sock, length).
> 
> i.e. how is the length related to the receive buffer of TCP

"
The Length argument is only meaningful when the socket is in raw mode and 
denotes number of bytes to read.
"
There is no connection between length and the receive buffer of TCP.
(perhaps you would like to explain what you mean by "the receive buffer
of TCP" since that might change my answer :-)

> So far the only difference in behavior I have seen is that the active
> socket reads every message it receives and sends it to the application,
> while a passive socket requires the user to read the socket. I am
> assuming that reading of the socket at intervals rather than
> continuously introduces flow control.

Correct.

> If my above assumption is correct -  how frequent should the read be to
> introduce an optimum flow control mechanism? How many bytes do we read
> at a time? Does the length parameter control the size of the receive
> buffer/advertised receiver window? How much of additional flow control
> do we achieve by using the timeout parameter in gen_tcp:recv/3 

The optimum flow control depends upon the application. Do you have any
data about yours?
You should read as many bytes as you want/need.
There is no connection between Length and "receive buffer/advertised
receiver window". The latter exist in the OS kernel (unless you have a
micro-kernel) and a user process can not change them. Some OSs even need a
re-compile to change them.

> Can I have two different processes interacting with the passive socket
> -  one process reads the socket in a loop while the other sends to the
> socket? I was thinking about this to free the process which would
> otherwise be tied to the receive loop.

This would work. Have you considered a gen_tcp:recv process that sends suitably 
tailored messages to a send/receive process?

> Would this beat the whole purpose
> of the passive socket? 

No.

> What are the default values of the send/receive buffer in OTP? I
> understand that these are set by the OS and are also configurable when
> we define the socket parameters but if this is not defined by the user
> does OTP override the OS defaults (possibly?)

No idea (but why should OTP do such a thing?).

> I am sorry about the long list of questions but I have used all
> resources I could find and have come to a dead end. Hopefully the
> experts on this list can help me out:))

Since no experts answered I thought I would give it a try instead.

> Also - Is there any documentation which explains in detail the
> implementation of sockets in OTP (other than the man pages). Especially
> how flow control and congestion control is implemented. 

Flow control in TCP is best explained by Stevens in his TCP/IP books
(book number 1 for this question).


Perhaps you are interested in TCP/IP implementation and not TCP/IP
usage? Erlang uses TCP/IP in gen_tcp, it does not implemet it. That is
left to the OS.


bengt