DISQUS

DISQUS Hello! 20bits is using DISQUS, a powerful comment system, to manage its comments. Learn more.

Community Page

Jump to original thread »
Author

Erlang: A Generalized TCP Server | 20bits

Started by Jesse Farmer · 7 months ago

No excerpt available. Jump to website »

17 comments

  • What are you using for your code highlighting? It looks great.
  • Kyle,

    I'm using geshi with an Erlang syntax plugin I wrote myself.
  • Jesse, thanks for this really useful overview! This is my first exposure to gen_server and gen_tcp and I would have been lost without this.
  • You should probably explain why with the echo server up and running,
    compiling echo_server.erl twice in a row kills the server.

    This is really frustrating to someone coming from lisp where
    hot code updates trully "just work" and things do not fail
    mysteriously. I have been trying to find out the cause of
    this behavior for the past hour with no success.
  • Ok so apparently erlang keeps 2 versions of module code (old and current)
    and processes that run old code are purged (killed). This is badly
    explained almost everywhere i've looked and examples are scarce to come
    by for something so important. So my next question then is how to
    do a hot code update without killing the tcp server or dropping any existing
    connections. After all this is erlang where 99.999% availability can be achieved
    this trivial task (which you get for free in common lisp without having to do
    anything special) should be possible.

    After hours of scavenging in badly written documentation, trying to understand
    the monstrosity that seems to be OTP (also noticed that pragmatic programming: erlang
    conveniently pushes this issue under the rug) i still have found no solutions.
    It seems everywhere i look at these days, proponents of erlang keep rambling about
    "scalability, availability, hot code updates" as if these are things that can be
    magically gotten for free. Well if "hot code updates" is how things are done in erlang,
    i will have none of that.
  • There's some switching around you can do with code:purge/1 and code:load_file/1 that I don't completely understand: http://gist.github.com/27901
  • Great article ! I was just wondering how I could make a TCP server using OTP gen_server after having read chapters 16 and 18 in Armstrong's book. Accept() was my problem and you solved it. Right on time
    :)
    I would also be interested in some informations about asynchronous accept. In fact I use "receive" and messages between processes to handle recv() on the socket. I do this because my process must have the ability to recv() and send() datas without knowing which one will come first. So it could be good for me to extend this style of managing things to accept() as well.
  • I think you can compile echo_server.erl twice in a row if you change loop(Socket); to ?MODULE:loop(Socket);

    Try it out.
  • @Jesse, would I be right in thinking that a TCP service exposed like this could in fact end up using millions of [erlang] processes and potentially hammer the system resources?
    I'm *very* new to erlang, so may not be following correctly, but it looks like a process is spawned for every "accept", so a malicious user could cause some trouble if the spawned process was actually doing something more intensive?.

    Thanks for the erlang posts, do keep them up if you can.
  • Have you submitted your geshi plugin to the geshi people?
  • Same question about the GeSHi Erlang support - have you submitted it?
  • Nice.

    Given the constant need for something like gen_tcp, why on earth haven't they added one to the official Erlang/OTP bundle?
  • Thanks a lot,
    you solution is super great!
  • there is still some "magic" that is not explained here.
    in socket_server:start() how does "loop" get mapped in the socket_server code?
    I mean where does the "loop" function that gets passed in actually get called?
  • The loop is stored in the State#server_state record, which gen_server passes to each of its callbacks.
  • So, what's the advantage of using gen_server here? Looks to me like most of the gen_server abstraction is actually being bypassed just to get it to work with TCP.
  • The stubs at the bottom are there because I didn't have time to implement them and I didn't think they'd improve the example.

    But the gen_server behavior has a lot to offer, especially if you want to make your server more robust.

Add New Comment

Returning? Login