1. Application Protocols
Lecture 12 part 1
Application Protocols

2. Protocol Communication Rules
syntax : how do we phrase the information we exchange.
semantics : what actions/response for information received.
synchronization : whose turn it is to speak (given the above defined semantics).

3. Protocol Initialization (hand-shake)
communication begins when party sends initiation message to other party.
synchronization - each party sends one message in a round robin fashion.

4. TCP 3-Way Handshake Establish/ tear down TCP socket connections
computers attempting to communicate can negotiate network TCP socket connection
both ends can initiate and negotiate separate TCP socket connections at the same time

5. TCP 3-Way Handshake (SYN,SYN-ACK,ACK)

6. What happens behind accept()
A sends a  SYNchronize packet to B
B receives A's SYN
B sends a SYNchronize-ACKnowledgement
A receives B's SYN-ACK
A sends ACKnowledge
B receives ACK. 
TCP socket connection is ESTABLISHED.

7. Message Format
Protocol syntax: message is the atomic unit of data exchanged throughout the protocol.
message = letter
concentrate on the delivery mechanism.

8. Framing streaming protocols - TCP separate between different messages
all messages are sent on the same stream, one after the other,
receiver should distinguish between different messages.
Solution: message framing - taking the content of the message, and encapsulating it in a frame (letter - envelop).

9. Framing – what is it good for?
sender and receiver agree on the framing method beforehand
framing is part of message format/protocol
enable receiver to discover in a stream of bytes where message starts/ends

10. Framing – how? Simple framing protocol for strings:
special FRAMING character (e.g., a line break).
each message is framed by two FRAMING characters at beginning and end.
message will not contain a FRAMING character
framing protocol by adding a special tag at start and end.
<begin> / <end> strings.
avoid having <begin> / <end> in message body.

11. Framing – how?
framing protocol by employing a variable length message format
special tag to mark start of a frame
message contains information on message's length

12. Many protocols exchange data in textual form
Textual data
Many protocols exchange data in textual form
strings of characters, in character encoding, (UTF-8)
very easy to document/debug - print messages
Limitation: difficult to send non-textual data.
how do we send a picture? video? audio file?

13. Binary Data non-textual data is called binary data.
all data is eventually encoded in "binary" format, as a sequence of bits.
"binary data" = data that cannot be encoded as a readable string of characters?

14. Binary Data
Sending binary data in raw binary format in a stream protocol is dangerous.
may contain any byte sequence, may corrupt framing protocol.
Option 1: a variable length message format.

15. Base64 Encoding Binary Data
Option 2: encode binary data using encoding algorithm
Base64 encoding - encodes binary data into a string
Convert every 2 bytes into 3 ASCII characters.
used by many "standard" protocols ( to encode file attachments of any type of data).

16. Encoding binary data
advantage: any stream of bytes can be "framed" as ASCII data regardless of character encoding used by protocol.
disadvantage - size of the message, increased by 50%.
(we will use UTF-8 encoding scheme)

17. Encoding using Poco
In C++, Poco library includes module for encoding/decoding byte arrays into/from Base64 encoded ASCII data.
functionality is modeled as a stream "filter"
performs encode/decode on all data flowing through the stream
classes Base64Encoder / Base64Decoder.

18. Encoding in Java iharder library.
modeled as stream filters (wrappers around Input/Output Java streams).

19. Protocol and Server Separation
Code reuse is one of our design goals!
Generic implementation of server, which handles all communication details
Generic protocol interface:
Handles incoming messages
Implements protocol's semantics
Generates the reply messages.

20. Protocol-Server Separation: protocol object
Protocol object is in charge of implementing expected behavior of our server:
What actions should be performed upon the arrival of a request.
Requests may be correlated one to another, meaning protocol should save an appropriate state per client.
E.g. authentication (logins)

21. A software architecture that separates tasks into separate interfaces

22. The actions that need to be performed by the server
Accept new connections.
Receive new bytes from the connected client.
Parse the bytes ointo masseges (called “de- serialization”, “unframing”, or “decoding”).
Dispatch the message to the right method to execute whatever the request specifies.
Send back the answer.

23. Interfaces & classes We define the following interfaces:
ConnectionHandler: Handles incoming messages from the client.
Holds the Socket, the MassageEncoderDecoder and the MessagingProtocol instances.
MessageEncoderDecoder: implements the protocol's syntax
Encoding and decoding messages from and to bytes.
For simplicity we will encode messages as UTF-8 text.
MessagingProtocol: implements the protocol's semantics.
Handling the received messages and generating the appropriate responses.

24. MessageEncoderDecoder
In charge of parsing a stream of bytes into a stream of messages and backwards.
It is a filter that we put between the Socket input stream and the protocol.
The protocol receives the messages from the EncoderDecoder. Does not access the steams directly.
This way we can replace the messaging formats but keep the protocol.

25. MessageEncoderDecoder
MessageEncoderDecoder works in byte-to-byte fashion.
If we decode a byte that together with the previous bytes represents a message:
We return the message.
We restart the decoding procedure.

26. MessageEncoderDecoder

27. MessagingProtocol
Receives incoming messages and executes the actions requested by the client.
Needs to look at the message and decide what needs to be done.
The decision may depend on the state of the client (e.g. authenticated?).
Once the action is performed we expect to get an answer to send the client.

28. MessagingProtocol
We allow to use any type of message (T).

29. Implementations ConnectionHandler
The server accepts a new connection from a client, and creates a ConnectionHandler
Handles incoming messages from the client.
Holds the Socket, the MassageEncoderDecoder and the MessagingProtocol instances.
Tcp socket - a pair of InputStream and OutputStream.
Designed to run by its own thread (Runnable).
It handles a connection to a client for the whole session
From the moment the connection is accepted, until one of the sides closes the connection.

30. ConnectionHandler Generic – works with any protocol.
Receives the socket (sock) from the server (the output of accept()).

32. MessageEncoderDecoder implementation for “echo server”
Echo server: The server sends back an identical copy of the data it received.
We use a framing method based on a single character FRAMING.
Specifically, we use ‘\n’.

35. MessagingProtocol implementation for “echo server”
When the server receives a message:
It prints it on the screen (on the server side) together with the time it received.
Then, returns it back to the sender while repeating the last two chars a couple of times.
That is, if a client send to the server the line "hello" it will be responded with the line “[time] hello .. lo .. lo ..“
Also supports a “bye” message which causes the server to close its connection.

38. Implementations
Connection Handler
MessageEncoderDecoder

39. Concurrency Models of TCP Servers
The actual server - an object that listen to new connection and assigned them to connection handlers.
Server quality criteria:
Scalability: capability to server a large number of concurrent clients.
Low accept latency: acceptance wait time.
Low reply latency: reply wait time after message received.
High efficiency: use little resources on the server host (RAM, number of threads CPU usage).
A TCP server should strive to optimize the following quality criteria:

40. Generic base server implementation

42. Some notes
Supplier - an interface in java that has one non default function called get(). A factory is a supplier of objects.
Our TCP server needs to create a new Protocol and EncoderDecoder for every connection it receives.
Since it is generic, it does not know how to create such objects.
This problem is solved using factories, the server receives factories in its constructor that create those objects for it.

43. Concurrency models
To obtain good quality, a TCP server will most often use multiple threads.
We will now investigate three simple models of concurrency for servers.
Single thread.
Thread per client.
Constant number of threads.

44. Server Model 1: Single Thread
One thread for:
Accepting a new client
Dealing requests, by applying run method of the passive ConnectionHandler object.

45. Single Thread Model: Quality
no scalability: at any given time, it serves one client only.
high accept latency: a second client must wait until first client disconnects.
low reply latency: all resources are concentrated on serving one client.
good efficiency: server uses exactly the resources needed to serve one client.
Suites only in cases where the process time is small (echo/linePrint).

47. Server Model 2: Thread per Client
Assigns a new thread, for each connected client.
In execute(), it allocates a new thread.
Invokes the start() method over the runnable ConnectionHandler object.

49. Model Quality: Scalability
Scalability: server can serve several concurrent clients, up to max threads running in the process.
RAM - each thread allocates a stack and thus consumes RAM
Approx threads become active in a single process.
The process does not defend itself – keeps creating new threads - dangerous for the host.

50. Model Quality: Latency
Low accept latency: time from one accept() to the next accept() is the time to create a new thread
short compared to delay in incoming client connections.
Reply latency: resources of the server are spread among concurrent connections.
As long as we have a reasonable number of active connections (~hundreds), load requested relatively low in CPU and RAM,

51. Model Quality: Efficiency
Low efficiency: server creates full thread per connection,
connection may be bound to Input/Output operations.
ConnectionHandler thread blocked waiting for IO still use the resources of the thread (RAM and Thread).

52. Server Model 3: Constant Number of Threads
Constant number of 10 threads (given by the Executor interface of Java)
Adding runnable ConnectionHandler object to task queue of a thread pool executor

53. Model Quality
Avoids host crash when too many clients connect at the same time.
Up to N concurrent client connections -server behaves as "thread-per-connection"
Above N, accept latency will grow
Scalability is limited to amount of concurrent connections we believe we can support.