Using Erlang, C And Lisp To Fight The Tsunami Of Mobile Data
highscalability.com
Using Erlang, C And Lisp To Fight The Tsunami Of Mobile Data
1–10 of 33 posts
Re: Using Erlang, C And Lisp To Fight The Tsunami Of Mobile Data
#2I'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
#3Self-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
#4Re: Using Erlang, C And Lisp To Fight The Tsunami Of Mobile Data
#5Self-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
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
#6Self-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?
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
#7On 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.
Re: Using Erlang, C And Lisp To Fight The Tsunami Of Mobile Data
#8Re: Using Erlang, C And Lisp To Fight The Tsunami Of Mobile Data
#9Re: Using Erlang, C And Lisp To Fight The Tsunami Of Mobile Data
#10It would be nice to know how many man-hours it took them to get this system from 0/idea to production and how many people were in the team...