File:  [NetBSD Developer Wiki] / wikisrc / examples / socket_programming / Attic / comment_4_bb9a3ffb0fd31f3bc7d151ec9b8f9e02._comment
Revision 1.1: download - view: text, annotated - select for diffs
Tue Mar 22 14:14:35 2016 UTC (4 years, 8 months ago) by wiki
Branches: MAIN
CVS tags: HEAD
web commit by shameem9002@f2ecf1bc7c685f538a5c0da5b06c5199757d0937: Added a comment: socket network programming

[[!comment format=mdwn
 username="shameem9002@f2ecf1bc7c685f538a5c0da5b06c5199757d0937"
 nickname="shameem9002"
 subject="socket network programming "
 date="2016-03-22T14:14:32Z"
 content="""
==============================================================
C Programming Assignment
Course : Network Security for WASE2012
Group Assignment :
MIN students per group : 2
MAX students per group : 5
Grade will be a per-group grade.
Assignment given Date : 27-Feb-2016 (CS1)
Assignment Due on Date : 04-June-2016 (CS7)
==============================================================
Using NetBSD based sockets, implement a TCP client
and TCP Server to demonstrate trivially secure
file download from server.
Environment/Tools required:
Linux RHEL4/5/6 and gcc compiler and vi editor
(recommended)
Learning Objectives for student:
--------------------------------
1. Ability to understand documents and convert them to working code.
2. Understand Network Protocol messaging and parsing.
3. Ability to program with NetBSD Sockets via C API.
4. Manage multiple connections at a server side.
5. Manage the state of a connection at both client and server side.
5. Understand Binary vs Text and practical issues with Endianness.
6. Ability to effectively use fread, fwrite APIs for file management
- can also use read/write system calls.
7. Understanding Standards and compatibility issues.
Even though the same standard document is followed,
implementations become different and not interoperable.
- eg. A group's server may not work with another group's client
and vice-versa.
Deliverables:
- Each group is expected to write both the client and the server.
- The entire C source code for the server and client to be delivered.
- source code should be compilable and executable.
- if the given source does not compile properly
in Linux RHEL4/5/6 credit will be highly reduced.
- It is the students' responsibility to make sure that the
source code compiles and runs properly in Linux RHEL4/5/6.
- If a group's server/client are compatible with
other group's client/servers, it will receive more credit.
- Source code to be accompanied by a small text document
to indicate features implemented and any other notes.
- Deliverables to be emailed to the grader.
- Printouts not required (Go Green!)
Network Security - Programming Assignment
1 of 5
Details:
---------
1. The messaging mechanism is based on Type-Length-Value (TLV)
The Message Format is
TYPE Field ---- Length Field --- Value field ---------------
---- 8 bytes --- 4 Bytes int ---- buffer of length bytes ----
Note: If Length Field is ZERO, then the Value field is empty
which is still a perfectly valid message.
- eg. LOGINOK message - See details below.
2. TYPE Field is of size 8 chars and always uppercase.
Valid Types for Client messages are:
LOGIN, AUTH, GETFILE
Valid Types for Server messages are:
NEEDAUTH, LOGINOK, DATA, ERROR
As Type field is 8 bytes, it will employ 'SPACE' as padding.
i.e. LOGIN will be sent as \"LOGIN \"
3. The message exchange details are as below:
Client connects to the server.
LOGIN is the first message sent by the client.
Server replies with NEEDAUTH message.
Client sends back AUTH message as a reply to NEEDAUTH message
Server replies with LOGINOK if authentication successful, else
replies with ERROR and closes the connection.
Client if login was ok, i.e. received LOGINOK message,
can start sending GETFILE requests.
Note: Only ONE outgoing request must be in the network pipe.
Upon receiving a GETFILE message, if server finds a matching file
it sends the file contents back in the DATA message.
If no matching file, it sends an ERROR message.
4. Note, at any time the client can close the connection and go away,
- server needs to detect this and close the connection
on its side as well.
eg. if while server is sending a file, the client goes away,
server needs to stop the transmission then and there
gracefully and should not crash.
As it is the server, other client connections
should not get affected.
- Same applies to the client, if server is stopped or crashed,
client should not hang or crash and should handle the scenario
gracefully.
5. The Client upon receiving the DATA message stores the contents
to a file and inform the same to the user.
6. Server never advertises the file list on the server
(unlike SCP/SFTP/FTP !)
- so clients need to know the file names
- a simple way is to query the user
Note: A fancy UI is not required, rather a basic working UI
with scanf() or fgets() should suffice.
Network Security - Programming Assignment
2 of 5
Note about GETFILE and security:
- If server is running from directory '/server/programs/docs/',
this is called the Working Directory of the server.
Server can only serve files under this working directory.
ie. /server/programs/docs/file1.txt
/server/programs/docs/file3.txt
/server/programs/docs/songs/song1.mp3
- But server cannot and must not serve files which are outside
the working directory.
eg. /home/user/file.txt
/server/programs/hello1.txt
The GETFILE message
eg. If \"hello/details.txt\" is sent, server is supposed to
look in its working directory for a matching file.
So in this case \"hello/details.txt\" and \"details.txt\"
may refer to completely different files.
Note about Auth Mechanism:
- Authentication here is based on a trivial Salted-MD5 mechanism.
- This avoids replay attacks.
- When server receives a LOGIN message, it checks if user is valid,
and if so, generates a random SALT eg. x9z0a42TXop1009qutyk
and sends it back in the NEEDAUTH message to the client.
- The client gets this NEEDAUTH message and uses the received SALT
and does a MD5(Password+SALT) and sends back in the AUTH message.
- The server upon receiving the AUTH message, checks the
MD5(Password+SALT) matches on its side.
- The server uses the credentials file for getting the
user and matching password.
* The server stores the list of users and passwords
in the credentials file.
- Yes this is Bad! Not secure, but ok for this assignment.
* Linux comes with a tool called 'md5sum' which can be used
to generate the Hashes on both client side and server side.
- There are many MD5 libraries available as well,
but do not use external MD5 libraries for this assignment.
Message Details
----------------
There are totally 7 messages - Syntax/Structure is as below.
1. LOGIN <username>
2. NEEDAUTH <Some salt data> - randomly generated
3. AUTH <hash>
4. LOGINOK
- no value sent. 0 byte length
5. ERROR
- can be 0 byte length or contain an error string
6. GETFILE <filepath>
7. DATA - x bytes indicating size + x bytes of data
Note: x can be 0. which means empty file!
Network Security - Programming Assignment
3 of 5
Command Line arguments:
-----------------------
./SServer <serverBindIP> <serverBindPort>
<serverWorkingDirectory> <credentialsFile>
./SClient <serverIP> <serverPort> <downloadStoreDirectory>
A Sample Messaging Session:
C - Client; S - Server
=============================================
C: LOGIN ramesh
S: NEEDAUTH aa1123
C: AUTH <MD5(Password + aa1123)>
S: LOGINOK
C: GETFILE detail.txt
S: ERROR \"No Such file\"
C: GETFILE details.txt
S: DATA 100 \"some data ... of 100 bytes\"
C: GETFILE docs.txt
S: DATA 129 \"some data ... of 129 bytes\"
Client closes the connection after receiving the DATA
and stores the data received into a file.
Notes on sanity testing:
* Both the server and client programs may run in the same machine
during development, but for testing it would be ideal to
run them in different machines, to see how a client/server
reacts when network goes away.
- Intentionally pull out the ethernet cable when the client
is downloading a big file and see if program misbehaves!
* Make sure the server side handling of BAD Clients is proper
- Clients may send BAD/Invalid Messages/Out-of-Sequence Messages
eg. A Client connecting and trying to send GETFILE Message
without sending LOGIN
Extras/Optional: - To be attempted only if the barebones
version as above is intact and working properly.
-----------------------------------------------------------------------
Server side :
1. Server can timeout an idle connection, where the idle timeout can be
set as a command line argument.
2. Server can intentionally allow only maximum 'y' number of downloads
(successful GETFILE + DATA) in a session.
After which it can return ERROR and close the connection.
'y' can be made configurable.
2. Server can close the connection if client sends 'x' number of bad
GETFILE messages. 'x' can be made configurable.
4. Implementing a simple Server side log with timestamp.
- which user downloaded which file with timestamp.
- + successful and failed login attempts with timestamp.
5. Server support for parallel multiple client connections
with select() and FDSET mechanism of checking socket data
availability or truly parallel threaded server!
Network Security - Programming Assignment
4 of 5
Client side:
1. Supporting Parallel Connections to download multiple files
from the server at a same time. eg. Via the UI can get the
list of files as input from the user and open multiple
parallel connections to the server, send the requests
to the server and start downloading the files at the same time.
- Will need to reuse the connections as well.
2. Implementing a simple Client side download log with timestamp.
3. Handling download of files with same names and download of the
same file multiple times.
eg. dir1/file1.txt and dir2/file1.txt
are distinct files on the server and when downloaded,
the client should not overwrite locally.
eg. if same file is downloaded twice, each filename will be unique
by suffixing it with a timestamp or counter mechanism as used
in Microsoft Windows. eg. FileName (1).txt
Extras (needs both server and client side co-operative changes)
- Support for TYPE : 'RANGE' to download a portion of the file.
RANGE message syntax:
---------------------
RANGE <filename> start end --- Value field has delimiter as CRLF \"\r\n\"
eg. RANGE details.txt
20
300
When server receives a RANGE message it sends the range requested only:
i.e. 20 to 300 bytes (both inclusive) and returns that data.
so data size will be typically end-start+1 bytes
in this case 300-20+1 = 281 bytes
Of course, if the file is much smaller than 300 bytes,
server can only send the available bytes.
Server should not choke on invalid RANGE values sent by a client,
if 'start' is greater than 'end', etc.
GRADING
--------
1. The correctness of the client and server program
2. Compatibility with other client and server implementations
3. Security of the program
- basic : handling of illegal input,
not choking on many connections
gracefully going down, etc.
4. Quality of written code
- employing proper abstracted functions
- correct usage of socket APIs
5. Attempting and completing any extra credit tasks.
- Grade will be a per-group grade. So all students in the group will receive
the same grade. So students are expected to work as a team and contribute
and share to the group for successful completion of the assignment.
---------------------------------------------------------------------------------------
Network Security - Programming Assignment
5 of 5
"""]]

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