[erlang-questions] Two beautiful programs - or web programming made easy

[Edmond Begumisa]

On Sun, 13 Feb 2011 21:18:53 +1100, Florian Weimer <fw@REDACTED>  
wrote:

> * 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  
workaround it.

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  
client would...

    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
    ..Headers..
    InnerMessage1
    InnerMessage2
    ..
    InnerMessageN

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  
desperation.

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

   --AaB03x
   content-disposition: form-data; name="message1"

   InnerMessage1
   --AaB03x
   content-disposition: form-data; name="message2"

   InnerMessage2
   --AaB03x

   ...

   content-disposition: form-data; name="messageN"

   InnerMessageN
   --AaB03x--

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:erlang-questions-unsubscribe@REDACTED
>


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/