If there is no test evidence deduct 1 mark for each point that has no test

If there is no test evidence deduct 1 mark for each

This preview shows page 8 - 10 out of 13 pages.

some test evidences. If there is no test evidence, deduct 1 mark for each point that has no test evidence. 4 Self-diagnosis: if there is no self diagnosis: deduct 10 marks 5 Self-diagnosis: if any bug is found in either the client or in the server, but is not mentioned in the self-diagnosis, deduct 1 mark. Do not deduct more than 10 marks under this item. 6 If source code is not supplied in the tar file: deduct 10 marks. 7 If the source code is not listed in the Word file, deduct 5 marks 8 Subtotal Marking Summary for the Simple File Transfer Protocol Project (a) Subtotal marks for Feature Check List: __________ (b) Subtotal deductions from Deduction Check List: __________ (c) Total raw marks ( (a) – (b)) : __________ (d) Number of days late (without extension): __________ (e) Late Penalty (5% of raw mark per day): __________ (f) Final project mark ( (c) – (e) ): __________ 8
Image of page 8
The Requirement for Protocol Specification: The protocol specification must be concise and logically complete with no ambiguity. The spec must not contain anything that is purely implementation related. Since the TCP is used to transport the messages, the receiver of a message will not see the message boundary. Therefore the message must be constructed in such a way to make it possible for the receiver to correctly receive the message. Watch out for the following types of errors: does not specify the underlying transport layer protocol that this protocol uses to deliver messages (must be TCP) does not specify default the server port number the message cannot be accurately received by the receiver. For example sending a file name without specifying the length of the file name or defining a special delimiter to signal the end of the file name. the message exchange sequence is not clearly defined or is confusing, or is logically inconsistent, or incomplete. the data encoding is not clearly specified. For example the words such as "a number" are not clear in terms of the encoding used (such as 32 bits with 2's compliment, or two ASCII digits etc). mixes up the presentation issues with protocol specifications. For example, the server may need to report to the client that the requested file does not exist in the server machine. Such an error message should be coded as one or two characters or a specific number value in the message, with its meaning defined in the protocol, rather than sending a character string such as "Error: the file does not exist". This is because how the client presents the error information to its user is a presentation issue and should be left to the client program to decide. For example the client may print the above string to inform its user, or it may display a picture to convey the same message, or to display the message in a foreign language. The protocol should not dictate how the program should present such a message to its user.
Image of page 9
Image of page 10

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture