Live data from Hacker News

Using Erlang, C And Lisp To Fight The Tsunami Of Mobile Data

highscalability.com

1–10 of 33 posts

Re: Using Erlang, C And Lisp To Fight The Tsunami Of Mobile Data

#2
Self-made Lisp, in-memory database and hacking the Linux kernel: what's not to like about it ; )

I'm wondering: how does one decide to change the TCP_TIMEWAIT_LEN from 60 seconds to 20 seconds? 20 seems an arbitrary picked value: I understand that by doing so they can drastically cut down on the number of open connections after the last FIN is received, but why 20 instead of, say, 17 or, say, 9?

Re: Using Erlang, C And Lisp To Fight The Tsunami Of Mobile Data

#3

Self-made Lisp, in-memory database and hacking the Linux kernel: what's not to like about it ; ) I'm wondering: how does one decide to change the TCP_TIMEWAIT_LEN from 60 seconds to 20 seconds? 20 seems an arbitrary picked value: I understand that by doing so they can drastically cut down on the number of open connections after the last FIN is received, but why 20 instead of, say, 17 or, say, 9?

On linux echo 20 > /proc/sys/net/ipv4/tcp_fin_timeout

Re: Using Erlang, C And Lisp To Fight The Tsunami Of Mobile Data

#5

Self-made Lisp, in-memory database and hacking the Linux kernel: what's not to like about it ; ) I'm wondering: how does one decide to change the TCP_TIMEWAIT_LEN from 60 seconds to 20 seconds? 20 seems an arbitrary picked value: I understand that by doing so they can drastically cut down on the number of open connections after the last FIN is received, but why 20 instead of, say, 17 or, say, 9?

On linux echo 20 > /proc/sys/net/ipv4/tcp_fin_timeout

The question was not "how do you do it once you decide" but "how do you decide on such an arbitrary replacement".

Also: "Do not be confused by the /proc/sys/net/ipv4/tcp_fin_timeout config item. The FIN TIMEOUT is not the same as the TIMEWAIT length." -- http://www.stolk.org/debian/timewait.html

Re: Using Erlang, C And Lisp To Fight The Tsunami Of Mobile Data

#6

Self-made Lisp, in-memory database and hacking the Linux kernel: what's not to like about it ; ) I'm wondering: how does one decide to change the TCP_TIMEWAIT_LEN from 60 seconds to 20 seconds? 20 seems an arbitrary picked value: I understand that by doing so they can drastically cut down on the number of open connections after the last FIN is received, but why 20 instead of, say, 17 or, say, 9?

I think the value of 20 seconds is arbitrary, but there's a good reason why they don't lower it any further. With a protocol like TCP that guarantees reliable delivery, sometimes packets get resent to the server. If the server receives this resent packet after the connection has been closed and a new connection has been opened, it is possible that the server will accept this packet. As such, as part of closing a TCP connection, the connection sits in a TIME-WAIT state for 2*MSL seconds (MSL = maximum segment lifetime).

If you decrease the amount of time a connection sits in a TIME-WAIT state, you will increase the probability that a new connection could receive a packet from a previous connection. Given the latency of mobile networks, I would expect the probability of receiving a packet from a previous connection to be even higher.

If you're interested, the beginning of the following paper provides a great overview of the problem: http://www.isi.edu/touch/pubs/infocomm99/infocomm99-web/

Re: Using Erlang, C And Lisp To Fight The Tsunami Of Mobile Data

#7
Why using a self-made lisp here ? Why not using an existing one ? Is it because regular lisps use a VM ? But then what's the tradeoff ?

On a side note, i really don't know if the savings will be worth it once the company starts growing and hiring. They'll spend a lot of time maintaining very custom code, running on a custom implementation of a language, alongside erlang codebase... Unless they open source everything to get a community to grow the user base for their tool.

Post reply on HN