Annotation of wikisrc/examples/socket_programming/comment_4_bb9a3ffb0fd31f3bc7d151ec9b8f9e02._comment, revision 1.1

1.1     ! wiki        1: [[!comment format=mdwn
        !             2:  username="shameem9002@f2ecf1bc7c685f538a5c0da5b06c5199757d0937"
        !             3:  nickname="shameem9002"
        !             4:  subject="socket network programming "
        !             5:  date="2016-03-22T14:14:32Z"
        !             6:  content="""
        !             7: ==============================================================
        !             8: C Programming Assignment
        !             9: Course : Network Security for WASE2012
        !            10: Group Assignment :
        !            11: MIN students per group : 2
        !            12: MAX students per group : 5
        !            13: Grade will be a per-group grade.
        !            14: Assignment given Date : 27-Feb-2016 (CS1)
        !            15: Assignment Due on Date : 04-June-2016 (CS7)
        !            16: ==============================================================
        !            17: Using NetBSD based sockets, implement a TCP client
        !            18: and TCP Server to demonstrate trivially secure
        !            19: file download from server.
        !            20: Environment/Tools required:
        !            21: Linux RHEL4/5/6 and gcc compiler and vi editor
        !            22: (recommended)
        !            23: Learning Objectives for student:
        !            24: --------------------------------
        !            25: 1. Ability to understand documents and convert them to working code.
        !            26: 2. Understand Network Protocol messaging and parsing.
        !            27: 3. Ability to program with NetBSD Sockets via C API.
        !            28: 4. Manage multiple connections at a server side.
        !            29: 5. Manage the state of a connection at both client and server side.
        !            30: 5. Understand Binary vs Text and practical issues with Endianness.
        !            31: 6. Ability to effectively use fread, fwrite APIs for file management
        !            32: - can also use read/write system calls.
        !            33: 7. Understanding Standards and compatibility issues.
        !            34: Even though the same standard document is followed,
        !            35: implementations become different and not interoperable.
        !            36: - eg. A group's server may not work with another group's client
        !            37: and vice-versa.
        !            38: Deliverables:
        !            39: - Each group is expected to write both the client and the server.
        !            40: - The entire C source code for the server and client to be delivered.
        !            41: - source code should be compilable and executable.
        !            42: - if the given source does not compile properly
        !            43: in Linux RHEL4/5/6 credit will be highly reduced.
        !            44: - It is the students' responsibility to make sure that the
        !            45: source code compiles and runs properly in Linux RHEL4/5/6.
        !            46: - If a group's server/client are compatible with
        !            47: other group's client/servers, it will receive more credit.
        !            48: - Source code to be accompanied by a small text document
        !            49: to indicate features implemented and any other notes.
        !            50: - Deliverables to be emailed to the grader.
        !            51: - Printouts not required (Go Green!)
        !            52: Network Security - Programming Assignment
        !            53: 1 of 5
        !            54: Details:
        !            55: ---------
        !            56: 1. The messaging mechanism is based on Type-Length-Value (TLV)
        !            57: The Message Format is
        !            58: TYPE Field ---- Length Field --- Value field ---------------
        !            59: ---- 8 bytes --- 4 Bytes int ---- buffer of length bytes ----
        !            60: Note: If Length Field is ZERO, then the Value field is empty
        !            61: which is still a perfectly valid message.
        !            62: - eg. LOGINOK message - See details below.
        !            63: 2. TYPE Field is of size 8 chars and always uppercase.
        !            64: Valid Types for Client messages are:
        !            65: LOGIN, AUTH, GETFILE
        !            66: Valid Types for Server messages are:
        !            67: NEEDAUTH, LOGINOK, DATA, ERROR
        !            68: As Type field is 8 bytes, it will employ 'SPACE' as padding.
        !            69: i.e. LOGIN will be sent as \"LOGIN \"
        !            70: 3. The message exchange details are as below:
        !            71: Client connects to the server.
        !            72: LOGIN is the first message sent by the client.
        !            73: Server replies with NEEDAUTH message.
        !            74: Client sends back AUTH message as a reply to NEEDAUTH message
        !            75: Server replies with LOGINOK if authentication successful, else
        !            76: replies with ERROR and closes the connection.
        !            77: Client if login was ok, i.e. received LOGINOK message,
        !            78: can start sending GETFILE requests.
        !            79: Note: Only ONE outgoing request must be in the network pipe.
        !            80: Upon receiving a GETFILE message, if server finds a matching file
        !            81: it sends the file contents back in the DATA message.
        !            82: If no matching file, it sends an ERROR message.
        !            83: 4. Note, at any time the client can close the connection and go away,
        !            84: - server needs to detect this and close the connection
        !            85: on its side as well.
        !            86: eg. if while server is sending a file, the client goes away,
        !            87: server needs to stop the transmission then and there
        !            88: gracefully and should not crash.
        !            89: As it is the server, other client connections
        !            90: should not get affected.
        !            91: - Same applies to the client, if server is stopped or crashed,
        !            92: client should not hang or crash and should handle the scenario
        !            93: gracefully.
        !            94: 5. The Client upon receiving the DATA message stores the contents
        !            95: to a file and inform the same to the user.
        !            96: 6. Server never advertises the file list on the server
        !            97: (unlike SCP/SFTP/FTP !)
        !            98: - so clients need to know the file names
        !            99: - a simple way is to query the user
        !           100: Note: A fancy UI is not required, rather a basic working UI
        !           101: with scanf() or fgets() should suffice.
        !           102: Network Security - Programming Assignment
        !           103: 2 of 5
        !           104: Note about GETFILE and security:
        !           105: - If server is running from directory '/server/programs/docs/',
        !           106: this is called the Working Directory of the server.
        !           107: Server can only serve files under this working directory.
        !           108: ie. /server/programs/docs/file1.txt
        !           109: /server/programs/docs/file3.txt
        !           110: /server/programs/docs/songs/song1.mp3
        !           111: - But server cannot and must not serve files which are outside
        !           112: the working directory.
        !           113: eg. /home/user/file.txt
        !           114: /server/programs/hello1.txt
        !           115: The GETFILE message
        !           116: eg. If \"hello/details.txt\" is sent, server is supposed to
        !           117: look in its working directory for a matching file.
        !           118: So in this case \"hello/details.txt\" and \"details.txt\"
        !           119: may refer to completely different files.
        !           120: Note about Auth Mechanism:
        !           121: - Authentication here is based on a trivial Salted-MD5 mechanism.
        !           122: - This avoids replay attacks.
        !           123: - When server receives a LOGIN message, it checks if user is valid,
        !           124: and if so, generates a random SALT eg. x9z0a42TXop1009qutyk
        !           125: and sends it back in the NEEDAUTH message to the client.
        !           126: - The client gets this NEEDAUTH message and uses the received SALT
        !           127: and does a MD5(Password+SALT) and sends back in the AUTH message.
        !           128: - The server upon receiving the AUTH message, checks the
        !           129: MD5(Password+SALT) matches on its side.
        !           130: - The server uses the credentials file for getting the
        !           131: user and matching password.
        !           132: * The server stores the list of users and passwords
        !           133: in the credentials file.
        !           134: - Yes this is Bad! Not secure, but ok for this assignment.
        !           135: * Linux comes with a tool called 'md5sum' which can be used
        !           136: to generate the Hashes on both client side and server side.
        !           137: - There are many MD5 libraries available as well,
        !           138: but do not use external MD5 libraries for this assignment.
        !           139: Message Details
        !           140: ----------------
        !           141: There are totally 7 messages - Syntax/Structure is as below.
        !           142: 1. LOGIN <username>
        !           143: 2. NEEDAUTH <Some salt data> - randomly generated
        !           144: 3. AUTH <hash>
        !           145: 4. LOGINOK
        !           146: - no value sent. 0 byte length
        !           147: 5. ERROR
        !           148: - can be 0 byte length or contain an error string
        !           149: 6. GETFILE <filepath>
        !           150: 7. DATA - x bytes indicating size + x bytes of data
        !           151: Note: x can be 0. which means empty file!
        !           152: Network Security - Programming Assignment
        !           153: 3 of 5
        !           154: Command Line arguments:
        !           155: -----------------------
        !           156: ./SServer <serverBindIP> <serverBindPort>
        !           157: <serverWorkingDirectory> <credentialsFile>
        !           158: ./SClient <serverIP> <serverPort> <downloadStoreDirectory>
        !           159: A Sample Messaging Session:
        !           160: C - Client; S - Server
        !           161: =============================================
        !           162: C: LOGIN ramesh
        !           163: S: NEEDAUTH aa1123
        !           164: C: AUTH <MD5(Password + aa1123)>
        !           165: S: LOGINOK
        !           166: C: GETFILE detail.txt
        !           167: S: ERROR \"No Such file\"
        !           168: C: GETFILE details.txt
        !           169: S: DATA 100 \"some data ... of 100 bytes\"
        !           170: C: GETFILE docs.txt
        !           171: S: DATA 129 \"some data ... of 129 bytes\"
        !           172: Client closes the connection after receiving the DATA
        !           173: and stores the data received into a file.
        !           174: Notes on sanity testing:
        !           175: * Both the server and client programs may run in the same machine
        !           176: during development, but for testing it would be ideal to
        !           177: run them in different machines, to see how a client/server
        !           178: reacts when network goes away.
        !           179: - Intentionally pull out the ethernet cable when the client
        !           180: is downloading a big file and see if program misbehaves!
        !           181: * Make sure the server side handling of BAD Clients is proper
        !           182: - Clients may send BAD/Invalid Messages/Out-of-Sequence Messages
        !           183: eg. A Client connecting and trying to send GETFILE Message
        !           184: without sending LOGIN
        !           185: Extras/Optional: - To be attempted only if the barebones
        !           186: version as above is intact and working properly.
        !           187: -----------------------------------------------------------------------
        !           188: Server side :
        !           189: 1. Server can timeout an idle connection, where the idle timeout can be
        !           190: set as a command line argument.
        !           191: 2. Server can intentionally allow only maximum 'y' number of downloads
        !           192: (successful GETFILE + DATA) in a session.
        !           193: After which it can return ERROR and close the connection.
        !           194: 'y' can be made configurable.
        !           195: 2. Server can close the connection if client sends 'x' number of bad
        !           196: GETFILE messages. 'x' can be made configurable.
        !           197: 4. Implementing a simple Server side log with timestamp.
        !           198: - which user downloaded which file with timestamp.
        !           199: - + successful and failed login attempts with timestamp.
        !           200: 5. Server support for parallel multiple client connections
        !           201: with select() and FDSET mechanism of checking socket data
        !           202: availability or truly parallel threaded server!
        !           203: Network Security - Programming Assignment
        !           204: 4 of 5
        !           205: Client side:
        !           206: 1. Supporting Parallel Connections to download multiple files
        !           207: from the server at a same time. eg. Via the UI can get the
        !           208: list of files as input from the user and open multiple
        !           209: parallel connections to the server, send the requests
        !           210: to the server and start downloading the files at the same time.
        !           211: - Will need to reuse the connections as well.
        !           212: 2. Implementing a simple Client side download log with timestamp.
        !           213: 3. Handling download of files with same names and download of the
        !           214: same file multiple times.
        !           215: eg. dir1/file1.txt and dir2/file1.txt
        !           216: are distinct files on the server and when downloaded,
        !           217: the client should not overwrite locally.
        !           218: eg. if same file is downloaded twice, each filename will be unique
        !           219: by suffixing it with a timestamp or counter mechanism as used
        !           220: in Microsoft Windows. eg. FileName (1).txt
        !           221: Extras (needs both server and client side co-operative changes)
        !           222: - Support for TYPE : 'RANGE' to download a portion of the file.
        !           223: RANGE message syntax:
        !           224: ---------------------
        !           225: RANGE <filename> start end --- Value field has delimiter as CRLF \"\r\n\"
        !           226: eg. RANGE details.txt
        !           227: 20
        !           228: 300
        !           229: When server receives a RANGE message it sends the range requested only:
        !           230: i.e. 20 to 300 bytes (both inclusive) and returns that data.
        !           231: so data size will be typically end-start+1 bytes
        !           232: in this case 300-20+1 = 281 bytes
        !           233: Of course, if the file is much smaller than 300 bytes,
        !           234: server can only send the available bytes.
        !           235: Server should not choke on invalid RANGE values sent by a client,
        !           236: if 'start' is greater than 'end', etc.
        !           237: GRADING
        !           238: --------
        !           239: 1. The correctness of the client and server program
        !           240: 2. Compatibility with other client and server implementations
        !           241: 3. Security of the program
        !           242: - basic : handling of illegal input,
        !           243: not choking on many connections
        !           244: gracefully going down, etc.
        !           245: 4. Quality of written code
        !           246: - employing proper abstracted functions
        !           247: - correct usage of socket APIs
        !           248: 5. Attempting and completing any extra credit tasks.
        !           249: - Grade will be a per-group grade. So all students in the group will receive
        !           250: the same grade. So students are expected to work as a team and contribute
        !           251: and share to the group for successful completion of the assignment.
        !           252: ---------------------------------------------------------------------------------------
        !           253: Network Security - Programming Assignment
        !           254: 5 of 5
        !           255: """]]

CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb