RNPP: Remote NotePad Protocol
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
[Pag.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
PREFACE
This document describes Remote NotePad Protocol (RNPP). This is the first edition of the specification of RNPP.
The lecturers Editors
[Pag.4]
Introduction
Remote NotePad Protocol (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.
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.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
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
[Pag.8]
Server methodology
Not described in this document in detail. Generally: 1. Server opens port number 56793.
2. 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:
Server Reply Message sent
by client
Reply code Text
01 User validation OK
10 Error, wrong user and/or password
11 Error, compulsory parameter is
missing
13 Error, unknown message
Validation
14 Error, unexpected parameters
03 ASCII string contained in remote
note bloc
10 Error, wrong user and/or password
11 Error, compulsory parameter is
missing
13 Error, unknown message
Request
14 Error, unexpected parameters
02 NotePad reception OK
11 Error, compulsory parameter is
missing
12 Error, too many characters
13 Error, unknown message
Modify
