-
Notifications
You must be signed in to change notification settings - Fork 0
Vidal Meeting Notes
Todos from last meeting are done.
Me: Contact Drew for feedback.
Todo:
- paper will need a Results section.
- Conclusion section, by Wednesday demo.
Work on updating paper. Met with client.
For next meeting:
- Work on slides explaining how algorithm works.
- The video should include an explanation of the algorithm, and then show the results of running the program.
- Have website, with video and paper.
- Have draft revision of paper by next meeting.
Second algorithm implemented.
I will get some feedback from client on quality of software.
Algorithms will be explained in paper, for final.
For RC1:
- Write pages explaining what the project is, step-by-step instructions on how to run it.
Spring break, no meeting.
Still working on adding limited capacity to server.
Working on d3.js implementation of graphic visualization.
for next meeting:
- beta:
- Add slider on time for the graph, so user can see how group allocation evolves over time.
- Add limited capacity to servers.
- Add second allocation algorithm: user chooses which one to run.
Joe did not attend.
Using dializer (static code analysis). Working on using EUnit.
Show simulator, balancing using Greedy algorithm, data is then shown on webpage.
Add graph visualization?
Add/kill clients/server at runtime?
For next meeting:
- Add slider on time for the graph, so user can see how group allocation evolves over time.
- Add limited capacity to servers.
- Add second allocation algorithm: user chooses which one to run.
Joe, new guy.
for next meeting:
- readup and install EUnit
- cleanup issues, add new ones.
- Joe can run project code
- demo
Demo: spawning actors, moving them to servers. Graph is generated from csv file which is written out by the program.
Work on making this into a 10minute demo.
Have simulator that spawns clients and servers, have another module separate from simulator that does the spawing.
December demo: the current scenario is good. For the demo it should be more dynamic: either new clients are added or clients move servers, they act. Write out a log file of events. Show some visualization of the events, by reading the log file and displaying it.
"Mathematical Problem" should become "Functional Requirements".
- Start work on visualization
- Separate Monitor messages from Algorithm messages.
Every server holds some clients, each belongs to a group.
The Master Server (MS) implements the algorithm (centralized solution). Tell new clients which server to go to, and move clients from one server to another when it determines its time.
The Master Controller (MC) controls the simulation.
Computation cost on the server goes up linearly? with number of clients on server. Thus, after some time the MS might decide to split a group.
Use built-in probability function to simulate how many messages clients send to each other, and (maybe?) how many messages are sent based on messages received.
TODO:
- Keep building simulator....
- Look into visualization.
Good progress on setting up the mathematical description of the problem.
You should talk to the client so you can define l[i][j] for different applications. For now, we have:
l_ij(f) = number of groups that have members in both i and j (2. in paper)
or
l_ij(f) = number of groups that have members in both i and j, multiplied(? or something) by the size of those groups. The idea is that in some cases there is a "master" client, so it would be better if there are many other clients from his group on his server, bad if the "master" is all alone in one server.
The problem is to minimize the sum of l_ij(f) for all i,j pairs. This solution assumes infinite capacity.
Your Job Find the algorithm that achieves a solution? Tip: start with a greedy strategy. That is, just place the next guy in the place that minimizes l_ij(f).
The main deliverable for this team will be a simulation, in Erlang.
TODO for next meeting:
- Work on building a simulator. You should have an implementation in Erlang of actors sending/receiving messages, maybe groups?
- Better description of the problem. Cleanup.
- Keep working on algorithm.
Team is researching and building load balancing algorithms for use with WebSocket, MQTT, and other protocols.
This project is not building a specific product. It is a research project. As such, you will follow the standard research methodology:
- Describe the problem in (mathematical) detail. Explain why its an important problem.
- Describe what a solution looks like. Provide an equation that measures the quality of a solution (say, 'total network load').
- Come up with various algorithms to solve the problem.
- Implement them.
- Test them, under different inputs.
- Analyze the results. Pretty graphs are required.
TODO for next meeting.
Instead of the Rough/Detailed Design milestones, this team will produce documents (wiki pages) which describe the problem. Specifically
- A mathematical description of the problem.
- A couple of sample scenarios using real technologies of where these types of problems arise.
Learn Erlang.