Building a cloud-hosted phone directory service (easy)
Your task is to flesh out the ideas seen in the video demo of Vsync into a full-fledged web search solution for a white pages phone service. It should support both lookup in a standard way, with the full name, but also inverse lookups (from phone number to
name) and partial name lookups (e.g. perhaps with a first name and a rough idea of the address).
Start by watching the video demo from above. This will really help, so don't attempt the project before you've watched the demo and understood the associated code -- you'll want to build on that code!
Now on paper, design the main components of your solution. These will include
- A client GUI. We recommend a web page that might look very similar to the ones you can find on the web for services of this kind. Use either a RESTful request/reply model, to a RESTful server, or the Windows Communication Foundation approach. RESTful solutions
are generally favored on Linux systems, and WCF is more popular on Windows, but they are pretty similar internally.
- A server. You will need to implement this first, so that when you implement the client you can get access to the web service API of the server. If you are working with the Windows Visual Studio C# editor, you'll find WCF very easy to access (they have
built-in support for it). The client can be coded in C++ too, or Python, or even C. On the server side, we recommend using C#, C++/CLI or IronPython (although we've build solutions that were coded in C, standard C++, and other languages too: the issue
is that there is some tricky code required to interface to Vsync in those cases).
Now debug your solution just with a single server and a single client. So far, you won't have used Vsync at all. You'll have spent a lot of time reading "how to..." man pages on the web -- we won't be offering those kinds of details here.
The server can probably hold the entire directory in its memory. In C# this could take the form of an ArrayList of entry objects, with one or more Dictionary indices to speed up access to the content. You could consider creating a fake directory to populate
the system. Make it fairly big: 10 million or more entries would be a minimum, and 100 million would be better. A full search done by your single server will be slow (obviously).
Once you have the code running, now modify the server to link with Vsync and to call VsyncSystem.Start() and VsyncSystem.WaitForEver(). Try launching two copies of this server on your own personal computer. Can you get them to discover one-another and start
up as a "single" Vsync system?
Finally, create a group for your directory service. The idea will be that as a request is received from your client GUI, you'll turn around and resend it as a Query within the group. Now all the group members can cooperate to subdivide the workload, which
lets you exploit parallelism for costly searches of the full directory. How close can you come to an N-fold speedup with N members in the group?
Follow-on ideas once you have the basic solution working: Add support for updates (e.g. a person moves but keeps her phone number, a person leaves entirely, or registers as a new customer, etc). Try running your server on Amazon EC2 or some other cloud hosting
service (you can apply for a small student account).