Distributed Systems: TCP vs UDP Protocols and Multi-Threaded Models

This report provides a detailed analysis of various aspects of distributed systems. It begins by contrasting TCP and UDP protocols, highlighting their differences in reliability and overhead, and providing application examples to justify their use cases. The report then compares multi-threading models, specifically thread-per-request and thread-per-connection, discussing their efficiency and scalability. Furthermore, it delves into the design and implementation of a TCP-based chat server using Java Socket programming, explaining the message exchange process and the use of object serialization. The document also covers digital signatures, the mutex algorithm, and various components like endpoints, RPC styles, and the use of wsimport tool in web services. The report concludes by differentiating between web servers and web services, providing examples of their functionalities. Desklib offers this document along with a wealth of solved assignments and study materials for students.

Distributed Systems

Table of Contents
1. Question 1...........................................................................................................................................1
1.1 Answer 1.1..................................................................................................................................1
1.2 Answer for 1.2............................................................................................................................2
1.3 Design and Implementation of TCP.........................................................................................3
2. Question 2...........................................................................................................................................4
2.1 Digital Signature........................................................................................................................4
3. Question 3...........................................................................................................................................4
3.1 Design and Implementation of Mutex Algorithm....................................................................4
4. Question 4...........................................................................................................................................5
4.1 End Point....................................................................................................................................5
4.2 RPC style....................................................................................................................................5
4.3 Look Up......................................................................................................................................5
4.4 4. Use of wsimport tool..............................................................................................................6
4.5 Web server and Web Service....................................................................................................6
References..................................................................................................................................................6

1. Question 1
1.1 Answer 1.1
TCP UDP
The benefits of TCP applications are less
transmission time and high unwavering
quality.
The application of UDP is that productive and
quick transmission like amusements. The
servers answer the small questions from
immense quantities of customers is the most
important stateless nature of UDP.
In TCP, there is unshakable certainty that the
information exchanged stays flawless and
lands in a similar request in which it was sent.
In UDP, there is no assurance that the
messages or bundles sent would reach by any
means.
TCP is substantial weight. It requires three
packages to set up a connection for
attachment, before any client information can
be sent. Blockage control unwavering quality
are handled by TCP
UDP is lightweight rather than TCP. So there
is no requesting of messages, no following
connections, and so on. It is a little transport
layer planned over IP.
Real Time Application Examples of TCP:
 Web
 IMAP/POP, getting mail
 SMTP, sending letters
 FTP, SSH, telnet
Real time examples of UDP:
 Games that run based on local
broadcast algorithm. So that we can
run the application various machines.
 Media streaming
 Tunneling/VPN
1.2 Answer for 1.2
Thread per request Thread per connection
Thread per-request for scales superior to
thread per-connection.
Less efficient rather than Thread per request.
In the Thread per request for display, the
thread is just related while a demand is being
prepared. That for the most part implies that
the administration needs less threads to deal
HTTP connection requires altogether less
assets than a thread stack, in spite of the fact
that there is a point of confinement of 64K
open connections for every IP address,

with a similar number of clients. What's more,
since threads utilize noteworthy assets that
implies that the administration will be more
adaptable.
because of the way that TCP/IP works.
1.3 Design and Implementation of TCP.
The code file is attached here.
It is a multithreaded customer/server ChatServer in view of comfort which utilizes Java
Socket programming. A server tunes in for association demands from customers over the system
or even from a similar machine. Customers know how to associate with the server by means of
an IP address and port number. In the wake of associating with the server, the customer gets the
chance to pick his/her username on the talk room. The customer communicates something
specific, the message is sent to the server utilizing ObjectOutputStream in java. Subsequent to
getting the message from the customer, the server communicates the message in the event that
it's anything but a private message. Furthermore, on the off chance that it is a private message
which is identify utilizing '@' trailed by a substantial username, at that point send the message
just to that client. Java protest serialization to exchange the messages.

2. Question 2
2.1 Digital Signature
Digital signatures depend upon open key cryptography; another name is deviated
cryptography (Noble, 2018). Open key calculations are utilized. For example, RSA, numerically
connected two keys are created. The status of the keys: one is private and other is open. Digital
signature programming (for example, an email program) will be made by agreeing the electronic
information from restricted hash. The hash will be encoded by using the private key. The
encoded hash along with other data like hashing calculation is called digital signature. The
explanation for scrambling the hash other than the record or whole message is that that a hash
capacity can be changed over a self-assertive contribution to settled length esteem, which is
normally significantly shorter. This spares time that the hash is probably faster than signing.
3. Question 3
3.1 Design and Implementation of Mutex Algorithm
• Safety - At most one process may execute in CS at any time.
– No deadlock too.

• Liveness – Every request for a CS is eventually granted
• Fairness – Requests are granted in FIFO (First In First Out) order and bounded wait
4. Question 4
4.1 End Point
Once an entrance token is gotten from OAuth2.0, the ProcessMaker REST endpoints can
be called utilizing that entrance token. This page discloses how to call REST endpoints utilizing
PHP, standard JavaScript and JQuery (which is a library of JavaScript). Since there is a ton of
code associated with conveying every HTTP ask for and preparing the reaction, it is prescribed
to make a custom capacity named pmRestRequest() that will deal with the REST asks. Utilizing
this capacity will improve our code and help keep away from duplication and
mistakes(Coulouris, 2012).
4.2 RPC style
rpc-style
To organize, in the solid depiction of the WSDL record, similar tasks can have diverse
SOAP ties. For this situation, each SOAP restricting can have an alternate namespace; this
decides the namespace of the root component of the message.
4.3 Look Up
For a customer to conjure a strategy on a remote question, it must get a reference to the
remote protest.
The RMI framework gives a remote protest registry that enables us to tie a URL-
organized name of the shape "//have/objectname" to the remote question, where objectname is a
basic string name.
The RMI registry is a basic server-side name server that enables remote customers to get
a reference to a remote question.
It commonly is utilized to find just the primary remote protest a RMI customer needs to
converse with. At that point, that first protest thus, gives application-particular help getting
references for different items. For instance, the reference can be acquired as a parameter to, or an
arrival esteem from, another remote technique call.

Once a remote question is enrolled in the rmiregistry, customers can:
 acquire a remote question reference (e.g., by finding it in the rmiregistry)
 Remotely conjure techniques on the protest.

4.4 4. Use of wsimport tool
When we compose our own particular customer bolster code then we need to do some
basic assignments, for example, utilizing right qualified name and the URL. Utilizing wsimport
summon we can create web benefit customer bolster code which handles the assignment of
including qualified name and URL. This data is exemplified. We will create web benefit
customer bolster code utilizing wsimport order.
4.5 Web server and Web Service
Web server:
It is a PC framework that handles customer's demand by means of HTTP convention.
Essentially, it just stores, process and conveys the static substance (or website pages) gave by
you. These can be utilized with modules to help scripting dialects like PHP, JSP, Python, and so
forth. Presently these servers can run any OS like Linux and Windows as an ordinary PC
frameworks does alongside extra administrations for server administration.
Web Service:
These are the strategies that give business rationale to your prerequisite. It is dialect or
OS free and gives the reaction in a specific arrangement like JSON, XML, and so on. Case: a
web benefit that gives data of a client in JSON
References
Coulouris, G. (2012). DISTRIBUTED SYSTEMS Concepts and Design Fifth
Edition. Pearsonhighered. Retrieved from http://www.pearsonhighered.com
Noble, B. (2018). Distributed Systems: Concepts and Design. Retrieved from
https://www.barnesandnoble.com/w/distributed-systems-george-coulouris/1100041111