Compare Proposal

Nothing to compare.

If someone calls the helpdesk, the staff creates a “Ticket” which describes the issue and helps trac

Urgent
  • Posted at : 1 month ago
  • Post Similar Project
156

Budget
17
Proposals
411
Views
Expired
Status
Skills Required

Posted By -

MD

0.0
Projects Posted : 1
Projects Paid : 0
Services Purchased : 0
Total Spent :
0
Feedbacks : 0 %

Project Details show (+) hide (-)










For each of the following tasks the client and the server side of the system have to be modified.
Furthermore, there is a shared part where modifications might be necessary. Import the provided
assignment template which consist of a multi-project Gradle build. There is a root project con-
taining sub-projects for the client, the server, and a shared one. You can import the root project
idstrsys into your IDE as existing gradle project. In Eclipse, all the sub-projects are imported as
own projects. An overview of these projects and what to do where is given in the following:



  • client: This project contains the Swing-GUI of the existing system. Additional “backend
    implementations” (at least one for UDP and one for AMQP) must implement the interface
    TicketManagementBackend and be registered. Check the JavaDoc documentation of the
    class Main for more details.



  • server: This project contains a very basic server backend implementation, which currently
    offers no remote access possibilities. Implement the Interface RemoteAccess and register
    your implementation as described in class Main of the server project.



  • shared: Contains all classes which are used on the server and the client side (i.e., the Ticket
    representations). You can also add additional classes, e.g., for UDP message formats if you
    like.



  • idistrsys: This project is the root project. For this assignment you might do configuration
    changes in it, but in general there are no changes necessary here.

    Part 1: UDP communication





  1. Basic level: Create the possibility to send a newly created ticket to the server by imple-
    menting the method createNewTicket(...) of the interface TicketManagementBackend
    and by providing a basic implementation of the RemoteAccess interface on the server side.
    A one way communication is sufficient here - so the createNewTicket(...) can return null,
    or an empty Ticket.



  2. Advanced Level: Of course, the basic solution is not really feature complete, so: Create
    a basic communication protocol in order to fully implement the TicketManagementBackend
    by adding the ability to update Tickets and to retrieve a list of existing Tickets from the
    server. Ensure that the server can handle multiple simultaneous requests from different
    clients concurrently.



  3. Even more advanced: As especially the ticket lists might be too large for a single UDP
    packet, it might be necessary to split the message into smaller chunks which are sent in
    multiple packets. Extend the basic communication protocol to split the packets at the
    sender side and to reassemble them on the receiver side. Be aware that the order of packets
    is not guaranteed by the UDP protocol.







2







Part 2: AMQP communication







  1. Basic Level: Implement a basic one-way communication protocol between the clients and
    the backend system. Ensure that messages are delivered to at least one Queue. Messages
    from the clients to the backend should be stored persistently in a Queue during forwarding.



  2. Advanced level: Improve the protocol to be able to receive replies from the backend server.
    As the number of clients is unknown, it is not possible to create the queues for the replies
    upfront. Therefore “temporary queues” have to be created during the runtime by the clients.



  3. Even more advanced: Create an additional Exchange, which forwards new messages to
    all registered clients when a new ticket is created or has been updated. The clients and the
    server must asynchronously receive messages by implementing a Push-API.



Optional Part 3: Server Backend system

The existing prototypic implementation is not threadsafe, which might cause trouble if more
and more clients are added to the system. Create another, threadsafe backend implementation
implementing the TicketStore interface!

Remarks and Constraints:



  • Use the provided template which contains already preconfigured gradle projects.



  • Read the javadoc documentation for the existing GUI and the prototypic backend server

    carefully! These comments describe how to adapt and extend the existing source code.



  • The backend system should be able to handle tickets via UDP sockets and AMQP in parallel!
    Moreover: It might be possible that more than one client submits tickets concurrently. How-
    ever, the client should either send messages using AMQP or UDP - switching the protocol
    during runtime is not needed.



  • Some additional remarks for the “even more advanced” UDP level:



    • –  There should be no limitations regarding the length of all fields of the newly created

      Tickets. I.e., it should be possible to use the full length of String and the other types.



    • –  If Tickets are splitted into multiple UDP packets, your solution should be able to deal

      with incorrect ordering. However, it is not needed that lost messages are resent.



    • –  Similarly the detection and resending of completely lost Tickets is not required... but
      if you have way too much time... ;-)





  • Some additional remarks for AMQP in general:



    • –  All needed components within RabbitMQ must be declared by the server and/or by

      the clients using the Java Client Library. Make a reasonable decision for each level!



    • –  You can use a Pull-API to receive messages in your implementation for the basic and
      the advanced level. However, using a Push-API is recommended.





  • As this is “Introduction to Distributed Systems” it should be possible (but not mandatory)
    to distribute the clients, the backend server and the AMQP broker on different machines.
    Of course this should be possible without recompiling your solutions. Pass host names and
    other information as arguments to the main classes. Document the correct usage of
    your solutions!