[erlang-questions] Two beautiful programs - or web programming made easy
Sun Feb 13 15:33:36 CET 2011
On Sun, 13 Feb 2011 21:18:53 +1100, Florian Weimer <>
> * Joe Armstrong:
>> How the heck can you easily send an an asynchronous message from a
>> client to
>> a server?
>> HTTP get and post wait for a reply and thus are synchronous.
>> By asynchronous I mean "fire and forget" like UDP.
>> If it easy easy them I'd love to know how ..
> XMLHttpRequest has an asynchronous option.
There seems to be some confusion. Forgive me, but aren't asynchronous HTTP
requests very different from asynchronous messages? Isn't the
"asynchronous" in XMLHttpRequest talking about the scripting environment
in relation to thread-blocking and not the messages themselves?
Asynchronous XMLHttpRequest just means that you can do something else
while you wait for the reply, but a failed reply is still a fault so the
message depends on the reply (or the reply can be viewed as part of the
message). XMLHttpRequest is just a workaround to allow single-threaded
scripting environments not to block so they can handle multiple requests
without introducing multi-threading, but you *always* have to deal with
the reply. My understanding is XMLHttpRequest in whatever mode does not
magically turn HTTP requests into asynchronous *messages*.
What is an "asynchronous message" anyway?
AFAIK, it means send and forget. For Erlang's case this is...
Recipient ! Message
From here on, you are free to go about your business and not have to deal
with any response. The recipient need not send you back any
acknowledgement to make the message "final". The message is thus
asynchronous because you send and forget.
Compare this with HTTP...
PUT /foo?message=Message HTTP/1.1
From here, the message is not complete until the server responds...
HTTP/1.1 201 Created [or 504 or whatever]
For XMLHttpRequest in synchronous mode, the scripting environment's thread
blocks until the message is concluded. For XMLHttpRequest in asynchronous
mode, the scripting environment's thread churns on but the message is
still not concluded until the reply arrives. The message is thus
synchronous either way because you don't send and forget, you have to
write code to deal with the reply.
Correct me if I'm wrong, but if you send and have to deal with a response
from the recipient, regardless of whether you can do something else as you
await the response, the message itself is not asynchronous. An HTTP
message consists of 1) send and 2) get reply, so is synchronous by
definition. XMLHttpRequest can't erase this, but it can allow you to
The workaround is an ugly hack that involves packing many "sub" messages
into the request and waiting forever for a reply while taking advantage of
non-thread-blocking in the scripting environment (i.e. comet/long-poll)...
So, to send truly asynchronous *messages* from server to client, the
GET /foo/comet_interface HTTP/1.1
Server responds, streaming back a reply while not concluding the reply for
as long as it can hold the connection open. It first sends headers, then
keeps appending the asynchronous messages...
HTTP/1.1 200 OK
Client then uses it's non-thread-blocking XMLHttpRequest to read the inner
messages as they arrive and tries not to close the connection. The client
has to know how to chop them up and the server might need to keep sending
a regular special heartbeat sequence when idle to keep the connection
open. So the "outer" HTTP GET message itself is synchronous (send and wait
for reply), but the "inner" messages packed inside are asynchronous (send
and forget). This is ugly, but web-developers have made it work out of
To send truly asynchronous messages from client to server is even tricker
and uglier. It might looks something like...
POST /foo/multipart_interface HTTP/1.1
Content-type: multipart/form-data, boundary=AaB03x
content-disposition: form-data; name="message1"
content-disposition: form-data; name="message2"
content-disposition: form-data; name="messageN"
Again, the "outer" HTTP POST message is synchronous (send and wait for
reply), but the "inner" messages are asynchronous (send and forget). This
hackery is harder than it needs to be.
> And you can get emulate a single full-duplex connection using two
> half-duplex ones,
Synchronous full-duplex messages are still synchronous messages. Both
sides still expect replies from the other, they can just do so at the same
time. What you can do, as illustrated above, is simulate asynchronous
messages with synchronous HTTP. And it's complete pain in the arse.
> so Websockets is just an optimization,
I disagree. WebSockets allow you to send asynchronous full-duplex messages
without the hackery of comet/long-polling. Just look at how clean Joe's
code is. A websocket-less version would be possible, but uglier.
> and likely not even a very much needed one.
IMO, the very fact that web-developers have frequently used various
workarounds proves that it's needed. There is a disconnect between what
web developers want and what the infrastructure currently provides.
Websockets tries to address some of that.
Personally, I think it's *very* much needed because it opens up the
possibilities of what you can do with the web-browser as a client. The web
browser starts to look more like a ordinary TCP client. You can do more of
the things that are easy with plain sockets which have always frustrated
me with browsers. Just look at Joe's idea. Those sorts of ideas don't
immediately spring to mind when you're stuck in the mindset of
uni-directional synchronous messages.
- Edmond -
> The barrier right now seems to be
> the BSD sockets API and kernel state management, and you still have
> that with Websockets.
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
More information about the erlang-questions