This task is about cross-language communication using remote procedure calls (RPC), using Apache Thrift. Implement a simple client-server application which will use given a communication protocol, and will be implemented in different programming languages. The protocol is based on a given language-independent interface description in Thrift IDL. Then, extend the protocol while maintaining full run-time compatibility.
The task requires understanding of the following:
The application that will be implemented is themed around a search service for a library. It is however designed to primarily show working with various data types using cross-language RPC, rather than perform any meaningful task.
The main idea is that the client logs in to the server, then lets the server perform a search for some library items (books, CDs or magazines). The result of the search is a list of items, which are returned to the client one by one. The client generates a summary based on the items and saves it on the server, which checks correctness of the summary.
Because the focus of this task is just the communication not an actual functionality of the application, we will work with just random data without any meaning.
The client and server should communicate like this:
Loginservice, with a user name an integer key.
InvalidKeyEception, which will contain the correct key.
logInagain, now with the correct key.
Bookand fetching them one by one.
fetchto fetch the items.
FetchResulteither contains an item from the result, or indicates why no item was returned.
ENDED, then no item was returned, because there are no more items (all were already fetched).
PENDING, then no item was returned, because the server is still searching for items and does not currently have any items to return.
ITEMS, then the
itemfield contains an item.
Implement a client which will communicate with the server using the protocol defined by the IDL file and the description above.
Test that the client works with our server at
Implement the server side of the application in C++.
login, you may use a random value per connection, or some hash of the user name.
library::Bookfrom items.hpp with the class
lib_services::Bookgenerated by Thrift. The firtst one was written by hand and is part of the data model of the database, the second one is generated based on the thrift IDL and is part of the commutnication protocol. You need to manually convert (field by field) an instance of
lib_services::Bookin order to pass it through Thrift.
__issetfield in C++, or
fetchto simulate a long-running search.
saveSummary, check that the summary is correct - you can use code in the file
summary.hppto generate the expected summary and compare it with the client-provided summary.
An important feature of Thrift and its IDL is the ability to evolve the interface while keeping compatibility.
For example, new fields can be added to user-defined types, fields which are not
required may be removed, function parameters may be added, etc.
The client and server may use different definition of a type or a function.
Magazine) in addition to
Magazine, which are defined in
items.hpp, add corresponding definitions to the IDL files.
Searchservice in some way to allow the client to initiate a search, specifying:
Searchservice in some way to allow fetching multiple items at once.
lib_services::Book, conversion from
lib_services::Magazineneeds to be implemented on a field-by-field basis.
Submit by e-mail, a zip file containing:
You must use the provided interface file and modify it only as described.
You may use the provided C++ code an modify it as you wish.
The server must be able to serve multiple clients at the same time without interference.
Do not crash or leak memory, perform undefined behavior, race conditions (if multiple threads access shared mutable data, the accesses must be synchronized, for example using a mutex lock).
Properly handle exceptions (do not crash or terminate just because the other side does not follow the protocol, etc.).
Keep the implementation simple.
It should be easy to build and run (preferrably should work on the computers in the school labs).
You may use parts of the example codes and scripts.
If you are using git to keep track of different versions, do not submit your git history - all parts of the solution should accessible directly as files.
If something is unclear, ask on the mailing list.