[erlang-questions] Setting socket options on listen / accept

[Tianxiang Xiong]

In Joe's Programming Erlang 2nd E, Chpt. 17, pg. 274, he says:

After we have accepted a connection, it’s a good idea to explicitly set the required socket options, like this:

{ok, Socket} = gen_tcp:accept(Listen),

inet:setopts(Socket, [{packet,4},binary,{nodelay,true},{active, true}]),

loop(Socket)

Until then the book's been doing:

{ok, Listen} = gen_tcp:listen(2345, [binary, {packet, 4}, {reuseaddr, true}, {active, true}])

{ok, Socket} = gen_tcp:accept(Listen),

...

loop(Socket)

Is there a reason we need to set the options after accept? Is it necessary to set options on listen and accept?

[Karl Velicka]

Hi, 

You don't have to set the options separately for accept, there's a two argument version that takes a proplist of socket options. 

When you're using gen_tcp:listen then you're setting up a server that receives connections, whereas `accept` is connecting to something that's listening to connections. You need to set the socket options separately in each case.

Hope that helps! 

_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Karl Velicka]

The case where you are in control of both the server and the client is not so common outside of book examples, so you'd be only configuring your end of the connection. And even when you control both, there can be many reasons for configuring your sockets differently. 

On 6 Feb 2018 08:20, "Tianxiang Xiong" <tianxia...@gmail.com> wrote:

OK, so the same options need to be set for listen / accept? That seems kind of redundant--is there a reason for that? Or are these usually different options?

[Karl Velicka]

Oh, my apologies! I was thinking about listen and connect - serves me right for replying before having a coffee :) In that case I don't really have a good answer for your question. 

On 6 Feb 2018 08:29, "Tianxiang Xiong" <tianxia...@gmail.com> wrote:

But listen and accept are both on the server side. Does that have anything to do w/ the client?

I'll have to read up more on the TCP protocol before investigating this further, I guess.

[Roger Lipscombe]

It's worth pointing out that certain 'raw' options only apply to the
listening socket, and are not consistently inherited by (or
transferred to) the accepting/connected socket. For example, on Linux,
TCP keep-alive settings can be applied to the listening socket, and
they'll be copied to the connected socket. On macOS, this (a) doesn't
work, and (b) does other weird, unexpected things.

Note also that you probably *don't* want to set {active, true} in
listen/2 in a real application, because you're probably going to hand
the socket off to another process (using
gen_tcp:controlling_process/2), and this'll cause you to miss the
occasional message during that window.

And, frankly, if you're building your own socket acceptor pool,
*don't*. Just use ranch (https://github.com/ninenines/ranch).

[Tianxiang Xiong]

OK, so the same options need to be set for listen / accept? That seems kind of redundant--is there a reason for that? Or are these usually different options?

On Tue, Feb 6, 2018 at 12:14 AM, Karl Velicka <karolis...@gmail.com> wrote:

[Tianxiang Xiong]

But listen and accept are both on the server side. Does that have anything to do w/ the client?

I'll have to read up more on the TCP protocol before investigating this further, I guess.

[Tianxiang Xiong]

Thanks Roger, that makes sense. And no, I'm not trying to build my own socket acceptor pool; that's probably too ambitious. Just working through Joe's book for now 😉.