1 / 70

Protocols

Protocols. Application Level Protocol Design. atomic units used by protocol: " messages " encoding reusable , protocol independent, TCP server, LinePrinting protocol implementation. Protocol Definition. set of rules, governing the communication details between two parties (processes)

lamar
Download Presentation

Protocols

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Protocols

  2. Application Level Protocol Design • atomic units used by protocol: "messages" • encoding • reusable, protocol independent, TCP server, • LinePrintingprotocol implementation

  3. Protocol Definition • set of rules, governing the communication details between two parties (processes) • different forms and levels; • protocols for exchange bits across a wire • protocols governing administration of super computers. • application level protocols - define interaction between computer applications

  4. 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).

  5. Protocols Skeleton • all protocols follow a simple skeleton. • exchange information using messages, which define the syntax. • difference between protocols: syntax used for messages, and semantics of protocol.

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

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

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

  9. A sends a  SYNchronize packet to B • B receives A's SYN • B sends a SYNchronize-ACKnowledgement • A receives B's SYN-ACK • A sendsACKnowledge • B receives ACK.  • TCP socket connection is ESTABLISHED.

  10. HTTP (Hyper Text Transfer Protocol) • exchanging special text files over the network. • brief (not complete) protocol description: • synchronization: client initiates connection, sends single request, receive reply from server. • syntax: text based, see rfc2616. • semantics: server either sends to the client the page asked for, or returns an error.

  11. What next? • syntax and semantics aspects of protocols. • assume: synchronization works in round robin, i.e., each party sends one message at a time.

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

  13. 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: messageframing - taking the content of the message, and encapsulating it in a frame (letter - envelop).

  14. 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

  15. 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. • message can be framed using <begin> / <end> strings. • avoid having <begin> / <end> in message body.

  16. 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

  17. 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?

  18. 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?

  19. Binary Data • Sending binary data in raw binary format in a stream protocol is dangerous. • may contain any byte sequence, may corrupt framing protocol. • Devising a variable length message format.

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

  21. Encoding using Poco • In C++, Pocolibrary 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 • classesBase64Encoder/Base64Decoder.

  22. Encoding in Java • iharderlibrary. • modeled as stream filters (wrappers around Input/Output Java streams).

  23. 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)

  24. Protocol and Server Separation

  25. 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.

  26. Protocol-Server Separation: protocol object • protocol object is in charge of implementing expected behavior of our server: • What actionsshould be performed upon the arrival of a request. • requests may be correlated one to another, meaning protocol should save an appropriate state per client.

  27. Example: authenticated session • protocols require user authentication (login), • only authorized users can perform certain actions. • protocol is statefull - serving requests of client can be in at least 2 distinct states: • authenticated (user has already logged in) • non-authenticated (user has not provided login). • by state of the protocol object, behavior of protocol object is different

  28. Protocol and Server Separation separate different tasks server must perform. • Acceptnew connections from new clients. • Receive new bytes from connected clients. • Parse incoming bytes from clients into messages ("de-serialization" / "unframing"). • Dispatchmessage to right method on server side to execute requested operation. • Send back an answer to a connected client after an action has been executed.

  29.  a software architecture that separates tasks into separate interfaces

  30. The key participants in this architecture are: • Tokenizer - syntax, tokenizing a stream of data into messages. • MessagingProtocol– semantics, handling received messages and generating responses.

  31. implementations of interfaces: • generic server • MessageTokenizer • LinePrinitingProtocol,

  32. Interfaces • implement separation between protocol and server. Define: • message (can be encoded in various ways: Base64, XML, text). • Our messages encoded as plain UTF-8 text. • framing of messages - delimiters between messages sent in stream. • protocol interface which handles each individual message.

  33. ConnectionHandler • server accepted new connection from client. • server creates ConnectionHandler- will handle all incoming messages from this client. • ConnectionHandler- maintains state of connection for specific client • Ex: user perform "login" -ConnectionHandlerobject remembers this in its state

  34. ConnectionHandler - Socket • ConnectionHandlerhas access to Socket connecting server to client process. • TCP server -  Socket connection is viewed as a pair of InputStream and OutputStream. • streams of bytes – client and the server exchange a bunch of bytes.

  35. Tokenizer- in charge of parsing a stream of bytes into a stream of messages • Tokenizerinterface: filter between Socketinput stream and protocol • Protocol accesses the input stream only through the tokenizer. • instead of "seeing" a stream of bytes, it sees a stream of messages. • Many libraries model such "filters" on streams as wrappers around a lower-level stream. • OutputStreamWriter - wraps stream and performs encoding from one character encoding to another • BufferedReader - adds a layer of buffering around a non-buffered input stream.

  36. Tokenizer • splits incoming bytes from the socket into messages. • For simplicity, we model the Tokenizer as an iterator… • protocol will see the input stream from the socket as an iterator over messages (instead of an iterator over bytes).

  37. Messaging Protocol • protocol interface • wraps together: socket and Tokenizer • Pass incoming messages to MessagingProtocol- execute action requested by client. • look at the message and decide on action • decision may depend on the state • Once the action is performed - answer back from the MessagingProtocol.

  38. We use a String to pass data from Tokenizerto Protocol, and back from Protocol. • Serialization/Deserialization (encode/decode parameters to/from Strings) performed by Protocol - and not by the Tokenizer. • Tokenizeris only in charge of deframing (split bytes into messages).

  39. Implementations

  40. Connection Handler • active object: • handles one connection to one client for the whole period during which the client is connected • (from the moment the connection is accepted, until one of the sides decides to close it). • modeled as a Runnable class.

  41. Connection Handler • holds references to: • TCP socket connected to the client, • Tokenizer • an instance of the MessagingProtocol.

  42. connection handler is generic, works with any implementation of a messaging protocol. • assumes data exchanged between client and server is in form of encoded strings • encoder passed to constructor as an Encoder interface.

  43. What’s left? • only need to implement: • specific framing handler (tokenizer) • specific protocol we wish to use. • continue our line printing example…

  44. Message Tokenizer • we use a framing method based on a single character delimiter. • assume stream of messages, delimited by FRAMING = we will use the character '\0‘

  45. important part is connection termination and exception handling at any moment • most of the code in low-level input/output and socket manipulation relates to error handling and connection termination.

More Related