Systems Programming Lec4 - Network Applications Programming part 2, Study notes of Computers and Information technologies

Download Systems Programming Lec4 - Network Applications Programming part 2 and more Study notes Computers and Information technologies in PDF only on Docsity!

11

Systems Programming

Network Applications Programming

Part 2

Application-level Protocols 1 The ‘application-level protocol’ defines how the parts of your application communicate. Consider an example with the following message exchange sequence: Client establishes connection with server Client sends player-name to server Server sends list of available players to client Client sends user-selection of opponent to server Server notifies client if the opponent is ready to play Server tells client if it is their turn to move, or wait. etc. … Server tells client if they have won, lost drawn. Client closes the connection. The ‘communication design’ consists of the following aspects: Message contents Message direction Handshaking / control Sequencing and Synchronisation

Protocol Data Units (PDU) Defining Application-level PDUs If there are more than one type of message, it is necessary for the receiver to be able to determine which particular type of message has been sent. e.g. some possible types of message that a game might need: Sign-on message (to server) Player move message (to server) Score notification message (to client) One way to be able to determine the message type is to add an extra field into the PDU structure to indicate message type such as int iMessage_type. For each message type, there will probably need to be a different ‘handler’. The value of iMessage_type will be used by the receiving process to determine which handler method to use.

Message types and contents For each type of message, we need to define the type and amount of content. For example: Message Message Data field Data type type name and length 1 Sign_on Player name 20 characters 2 Player_move Coordinates 2 integers 3 Score Player name 20 characters Player score 1 integer Opponent name 20 characters Opponent score 1 integer

Structures 2 However, to use the three structures on the previous slide, in the same application, requires that strict synchronisation is provided in the game logic. This is so that the receiver of a message always knows which message type to expect (because of the way it divides up the message content and processes it is different for each type of message). Strict synchronisation is quite restrictive. If this is not feasible (in many applications it is not possible to predict which type of message will need to be sent, in advance) then some other way of identifying the message type is needed. One approach is to use a large structure containing all possible fields, and to include a message-type field. Such as int iMessage_Type; The message type implies which fields are actually used at a particular time.

Structures 3 The three previous structures are combined together, removing any duplicate fields, but ensuring all unique fields are retained. In addition the iMessage_Type field is added: struct Game_message { int iMessage_Type; char cPlayerName[20]; int iPlayerScore; char cOpponentName[20]; int iOpponentScore; int iX_Coordinate; int iY_Coordinate; }; In this way, the receiver does not need to know in advance which type of message was sent. On arrival, it examines iMessage_Type. From this it knows which type of message it is, and by implication, which other fields to use and which to ignore.

Structures 5 To support up to 10 players an array of 10 structures may be declared: struct Player-Details Players[10]; To copy all the players score details into the message structure for sending: struct Game_message MessageToSend; int iPlayerIndex; for ( iPlayerIndex = 0; iPlayerIndex < 10; iPlayerIndex ++ ) { … MessageToSend. iPlayerScore[iPlayerIndex] = Players [iPlayerIndex]. iPlayerScore; … }

Sending a (structure) message (Client-side example) struct Game_message Message; // Create a new message instance Message.iMessage_Type = 1; // Set the type of message // Initialise rest of message structure here int iBytesSent = send( iSocket, (char*) &Message, sizeof(Message), 0 ); if(SOCKET_ERROR == iBytesSent) { MessageBox(“Send failed",“Game Client"); } }

An example message-type handler (Server-side example continued) Consider the main message loop contains a switch statement with: case 1 : Handle_SignOn_Message ( Message ); break; case 2 : … The class header will contain the declaration / prototype for the method: bool Handle_SignOn_Message ( struct Game_message Message ); The source code file for the class contains the implementation of the method: bool Class_name::Handle_SignOn_Message ( struct Game_message Message ) { (Find the appropriate connection details entry in the array) (if could not find entry) return false; strcpy( Connection_Array[iIndex].cName , Message .cPlayerName ); (send message to all attached clients, informing of new player) return true; }

Server and client lifetimes The Server will usually run for long periods. The client will usually be started when a user wants a service performed and have relatively short lifetimes. Thus ►the server does now know when a client will connect in advance. ►several clients may be connected at the same time. The server may need to maintain an array of connection structures (i.e. put all the information about each connection in one structure, and keep an array of these structures so they can be processed in a loop): struct PlayerConnection { // details of each connection are kept together SOCKET iPlayerSocket; SOCKADDR_IN PlayerSockAddr; bool bEntry_Is_In_Use; }; struct PlayerConnection PlayerConn[10]; // create an array of 10 structures These structures are then used in send / recv operations, (i.e. inside loops ): if(true == PlayerConn[iIndex]. bEntry_Is_In_Use) { iBytesSent = send(PlayerConn[iIndex]. iPlayerSocket, …..); }

Interpreting Visual Studio’s error messages 1 The compiler is a lot better at spotting syntax errors than most of us: ►if you learn to understand the error messages it gives you, and ►use the in-built help, most problems can be solved very quickly. The error messages identify the type of problem and the location where the problem was first noticed. Example 1 – this tells us that ‘SOCKET m_iSocket’ is missing in the header for the class contained in clientdialog.cpp

Interpreting Visual Studio’s error messages 2 Example 2 – This appears to report 4 errors. However, always start with the first error on the list. In this case there is a big clue in the class names; it tells us that the CClientDialog class name is not recognised inside the serverdialog class. On closer inspection is was found that the scope resolution had not been changed when some code was copied from the CClientDialog class. When this was fixed the other errors also disappeared.

Using Visual Studio’s in-built help / index / search 2 Resources include: methods, required header files and code examples.

Including a bitmap picture onto a control 1 First create a bitmap from within the ‘resource view’