Even if a million people check using all of these bandwidth savers, that’s still a million TCP connections being opened and closed. That’s just not going to scale well as we get larger and larger audiences.
This sounds like a simple interview question at Amazon - "so, how would you make it work anyway?". Okay folks, let's break some assumptions: Not every client has to connect to the One True Server. There is this concept of an 'intermediary'. You can use this to place a thousand caching servers that retrieve the data, then clients retrieve from those servers instead. One level of indirection gives you n*2 more scalability. Two levels give you how much? Anyone? Anyone?
And this:
HTTP servers can only speak when spoken to. They can’t just connect to the client, the client has to initiate the connection. Even with keep-alive, they still have to wait until an HTTP method is incurred. By not being able to have that two-way communication, how can we truly maintain HTTP as our protocol of choice?
Well, duh. Of course. And this is a unique problem because... what? The solution is simple and applies to any protocol - put a server on the desktop & send it a message. And for your next complaint in this sequence, here's a question for you - how is your pet protocol going to post messages to a desktop without the client opening a socket (like an http server) or initiating a connection (like an http client) of some kind?
See http://www.mod-pubsub.org/ for an example of a client that initiates a connection and then consumes a stream of event notifications on that connection. There are clients in multiple languages (Java, Perl, Python, C++) and even two servers (Perl, Python). The neat thing is, it's just HTTP, so all the documents & design has been done. You just have to follow in someone else's footsteps.
No comments:
Post a Comment