Files changed (1)
J: Now when you create a TCPSocket, it actually causes the Orbited server to create a tcp socket to the destination port and domain
J: Next, Orbited, takes that data, and writes it to the TCP socket. It doesnt care what the protocol is whatsoever, it just proxies any bytes that it receives.
-J: So when the back-end server sends some downward, Orbited will locate the appropriate live Comet connection
+J: So when the back-end server sends some data downward, Orbited will locate the appropriate live Comet connection and send that data to the browser. The browser receives it and calls the TCPSocket's onread function.
+J: So in essence, this TCPSocket api isn't just a way to communicate between the browser and the comet server. Its like the comet server doesn't exist -- its just a dumb proxy. Really, its a way to communicate between the browser and an *arbitrary* back-end TCP server.
+J: We aren't calling comet Sockets. We're putting sockets in the browser. And the best part is, because we're implementing sockets ON TOP of comet, it still traverses proxies and firewalls seamlessly, and works in any browser.
M: Yeah, but now you have to do more work in the browser. You'll be using extra cpu to parse IRC instead of just eval or safe evaling some json.
-J: Ok, so then it would only take 0.2% of the processor for the server to parse that protocol for the browser, right?
+J: Ok, so for one user it takes 10% of the processor. But c is 50 times faster, so divide that by 50. Therefore, it would only take 0.2% of the processor for the server to parse that protocol for the browser, right?
-J: That means that we would saturate the server with 500 users. So if you want any chance of scaling this stuff, you better not put it on the server!
+J: But hold on -- That means that we would saturate the server with 500 users. So if you want any chance of scaling this stuff, you better not put it on the server!
M: I see what you did there! Okay, so maybe I exagerated. It would take probably 1% of the processor to parse the js protocol
-J: Okay, then whats the problem? 1% of the cpu isn't a problem at all. The bottom line is this: If you parse the protocol on the server, scalability will be a big problem. On the other hand, distributing this work load to the clients allows massive scalability.
+J: Okay, then whats the problem? If the user's browser is only using 1% of the cpu, that isn't a problem for them at all -- Its pratically nothing.
+J: The bottom line is this: The server is *always* the bottleneck for any webapp. If there is some piece of the computing that you can do in the browser, then *do it in the browser*. Parsing the protocols can clearly happen on the server or the browser. But If you parse the protocol on the server, scalability will be a big problem. Therefore, distributing this work load to the clients allows massive scalability.
+J: Almost. We have one more component in Orbited which is an access control list. We only proxy connections to pre-configured destinations. The best way to describe orbited is as a web enabled Firewall.
+M: Thats interesting. So here's my question. I have a reasonable understanding how Gmail works -- its like a classic Comet deployment.
+M: For the chat, they have a web application that maintains a connection to the xMPP server for each applicaiton