RNPP: Remote NotePad Protocol. Computer Networking Program. Protocol Specifications. October Prepared for

Transcription

1 RC_RFC: 5 RNPP: Computer Networking Program Protocol Specifications October 2014 Prepared for Computer Networking, 2nd Year Grade of Computer Science Engineering University of Seville by Lecturers of the Computer Networking Subject Departamento de Tecnología Electrónica

2 CONTENTS PREFACE...3 Introduction...4 Protocol Operation...4 Message types...4 Message syntax...4 Message semantics...4 Client methodology...6 Validatation methodology... Error! Marcador no definido. Request methodology...7 Modification methodology...7 Server methodology...7 [Pag.2]

3 PREFACE This document describes (RNPP). This is the first edition of the specification of RNPP. The lecturers Editors [Pag.3]

4 Introduction (RNPP) is an application layer protocol that uses non-reliable transfer services of the transport layer in the TCP/IP architecture. It allows the client to keep a NotePad in a remote server. The NotePad is formed by a series of text lines. Protocol Operation Basic operation of RNPP protocol: The client can validate its user account in the server at any time, ask the server for the NotePad content, or modify it. Next, there is a description of the protocol features. Message types In RNBP protocol there are the following types of messages: Validation Reply Request Modify Message syntax Messages are always text strings in ASCII. Syntax for the message types in RNBP is the following: Message Syntax Validation val name password Reply RNBPv3 99 text_lines Request get name password Modify put name password text_lines Message semantics Then, the meaning of the different message types and their arguments are described: Validation val name password name is the NotePad owner s username. It must be alphanumeric and cannot contain spaces. password is the user s password. It must be alphanumeric and [Pag.4]

5 cannot contain spaces. This message allows the client to validate that the user has an account in the server. Modify put name password text_lines name is the NotePad owner s username. It must be alphanumeric and cannot contain spaces. password is the user s password. It must be alphanumeric and cannot contain spaces.text is an ASCII string with the contents of the NotePad. It can contain usual ASCII control characters to separate several lines in the text. Text_lines is an ASCII character string, which is the NotePad content. String can also contain ASCII control chracters, to delimitate the end of the text lines. This message allows the client to modify the content of the Note Bloc in the server. Request get name password name is the NotePad owner s username. It must be alphanumeric and cannot contain spaces. password is the user s password. It must be alphanumeric and cannot contain spaces. This message allows the client to request the content of the NotePad hosted by the server. [Pag.5]

6 Reply RNBPv3 99 text 99 is a two-digit status code, as detailed below. text is an ASCII string which contents vary depending on the reply code. It may be an informative message or even the NotePad content itself. Those informative messages do not have to be exactly the same as the ones shown below. Note that error status codes always start with 1. This message allows the server to inform the client of the status of the last command sent by the client. Reply code Text 01 User validation OK 02 NotePad reception ok 03 ASCII string from the NotePad 10 Error, incorrect username or password 11 Error, mandatory argument missing 12 Error, NotePad with too many characters 13 Error, unknown message 14 Error, too many arguments Client methodology RNBPv4 protocol requires that the server is on. Besides, it must have a list of all the usernames and passwords and all of them have an initially empty NotePad. The details are not explained in this document. Once the client has initiated a communication with the server, Validation procedure is set up. Once held, the client can execute Request or Modify procedures, as many times as desirable. When sending a message, the client must wait for a limited time for the server s response. If response does not arrive (it is possible, as the [Pag.6]

7 service is non-reliable), the client must re-send the message. A typical value for the waiting time may be 3 seconds. The client must also block the number of re-sendings, to avoid being blocked forever. Validation methodology: - Send validation message to server and wait for a reply message. - If reply code == 01 then USER IS VALIDATED - Else ERROR Request methodology: - Send request message to server and wait for a reply message - If reply code == 03 then NOTEPAD IS RECEIVED - Else ERROR Modification methodology: - Send modify message to server and wait for a reply message - If reply code == 02 then NOTEPAD IS UPLOADED - Else ERROR [Pag.7]

8 Server methodology Not described in this document in detail. Generally: 1. Server opens port number Every message received by the server is replied with a reply message. The message includes a status code depending on the success or not of the action. Next, there is a relation between requests and possible reply codes: Message sent by client Reply code Server Reply Text 01 User validation OK 10 Error, wrong user and/or password Validation 11 Error, compulsory parameter is missing 13 Error, unknown message 14 Error, unexpected parameters 03 ASCII string contained in remote note bloc 10 Error, wrong user and/or password Request 11 Error, compulsory parameter is missing 13 Error, unknown message 14 Error, unexpected parameters 02 NotePad reception OK Modify 11 Error, compulsory parameter is missing 12 Error, too many characters 13 Error, unknown message 14 Error, unexpected parameters [Pag.8]