CMU 15-418 (Spring 2012) Final Project:
Clientside loadbalancing & server side automatic provisioning for single page web applications.

Project Proposal

Checkpoint Report

Final Report

Working Schedule

Week What We Plan To Do What We Actually Did
Apr 1-7  investigate data models and calculations Reformat idea several times to address implementation issues.
Apr 8-14  prototype sequential and parallel implementationsDiscover that no implementation of previous topic is feasible. Decide to write parallel server. Research parallel server and prototype several inter-machine communication options.
Apr 15-21  test and debug Research load balancing options, implement robust non-blocking parallel java HTTP server, and break up with girlfriend.
Apr 22-28  implement server registration, performance observer, and work distributorimplement server parallellization and begin server intercommunication protocol
Apr 29-May 5  implement server side reference service and client side server discovery implement server intercommunication protocol along with object passing, implement clientside interaction
May 6-11  continue working until there are only a few hours remaining, then write report. complete load balancing algorithm, client dropping in instances, and client redirection on instanceRegistry, along with substantial debugging

Working Log

Neither risk analysis for a particular company nor global risk analysis are feasible. All companies use similar metrics based on academic research, but won't release them. Global risk analysis requires in depth domain knowledge that I don't want to get.

I can't find a better method than connecting over sockets to distribute a server accross the cluster. Basically I should copy the 213 textbook server and scale out.

Why am I using C. I should just use Java. Sockets are much easier in Java.

Java is the right way to go anyway, server's ought to be an abstract model to the client's javascript view-model. The client needs events to deal with presenting the data, but the server does processing on data and ought not to care how its output is rendered. The server ought to only send a single page, then only respond to ajax requests from the page. This isn't really REST because the client changes state without really following hyperlinks. REST isn't great anyway because although I know where the resource is, my javascript doesn't know what the hell it's going to get once I follow the link. Java ought to expose some sort of interface that the javascript can know about beyond the url of the resource. Oh well, I'll do that later.

It turns out that regular Java sockets are blocking and scale poorly. Non-blocking socketchannels aren't well documented. I finally found a guy who explains Java nio pretty well. I found another guy who does a much better job.

Do I have to use a front server as a proxy? Can't the end of the connection just change to a different machine? Turns out, no. Either something proxies (packets are forwarded, somebody redirects), or the client has to be told to go to a new server. If the client goes to a new server and that one breaks, then the client is out of luck.

OMG, the client's javascript should ask one tier of servers (which are loadbalanced themselves!) for access to the next tier. The second tier of servers remains hidden unless exposed, and when it breaks, the client returns to the first tier (who are duly suspicious of him and check that the server is indeed broken)