File:  [NetBSD Developer Wiki] / wikisrc / examples / socket_programming / Attic / comment_1_4fa1037d20f091573b81c12b8e1fde24._comment
Revision 1.1: download - view: text, annotated - select for diffs
Tue Jul 1 06:32:33 2014 UTC (6 years, 1 month ago) by wiki
Branches: MAIN
CVS tags: HEAD
web commit by https://www.google.com/accounts/o8/id?id=AItOawm4w8p8mQ2-kj0UGVKSlhhiAPbUYHlPpao: Added a comment: Using NetBSD based sockets, implement a TCP client and TCP Server to demonstrate trivially secure file download from server.

[[!comment format=mdwn
 username="https://www.google.com/accounts/o8/id?id=AItOawm4w8p8mQ2-kj0UGVKSlhhiAPbUYHlPpao"
 nickname="Ashish"
 subject="Using NetBSD based sockets, implement a TCP client and TCP Server to demonstrate trivially secure file download from server."
 date="2014-07-01T06:32:32Z"
 content="""
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/g++ compiler and vi editor
(recommended)
OR
Windows XP/Vista/7/8 with Visual studio.
Learning Objective for student:
--------------------------------
1. Understand Protocol messaging and parsing.
2. Manage multiple connections at a server side
3. Manage the state of a connection at both client and server side.
4. Ability to use NetBSD Sockets via C API.
5. 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 (and the inherent difficulty!)
between different (not differing!) implementations.
Note: This is a group assignment.
Each group can have maximum of 10 students.
- If group of 10 students is opted,
5 students may contribute to the client
and another 5 students may contribute to the server.
but put together at a minimum, the expected result is
a group's server should work with its own client.
- If a group's server/client are compatible with
other group's client/servers, it will receive more credit.
** Each group is expected to write both the client and a server.\"
-1-
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. All types are 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.
If server requires authentication, it replies with NEEDAUTH message.
If server does not require authentication, it replies with LOGINOK message.
Client sends back AUTH message as a reply to NEEDAUTH message
Server replies with LOGINOK if authentication successful, else
replies will reply with ERROR and close the connection.
Client if login was ok, i.e. received LOGINOK message, can send at any time,
a file download request by sending the message GETFILE.
Note: Only outgoing request must be in the network pipe.
Upon receiving a GETFILE message, if server finds a matching file
it can send the file contents back in the DATA message.
If no matching file, it may send back an ERROR message.
4. Note, 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 then and there.
-2-
5. The Client upon receiving the DATA message should store the contents
appropriately into a file for later viewing.
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.
Note about GETFILE:
The GETFILE message can send as value a full path name (absolute)
or a relative path name. with \"/\" as directory separator.
eg. If \"hello/details.txt\" is sent, server is supposed to
look in its working directory the given path of the file.
So in this case \"hello/details.txt\" and \"details.txt\" may refer
to completely different files.
Command Line arguments:
-----------------------
./TSServer <serverBindIP> <serverBindPort> <serverWorkingDirectory>
./TSClient <serverIP> <serverPort> <downloadStoreDirectory>
Note about Auth Mechanism:
Any 2-way auth mechanism can be employed, trivially a
Salted Password hash based mechanism can be employed.
This avoids replay attacks!
NOTE:
* If the environment chosen is Linux, it comes with a tool called
'md5sum' which can be used to generate the Hashes
on both client side and server side.
* The server can store the list of passwords in some file.
(Bad! Not secure, but ok for this barebones version)
* 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!)
-3-
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. O byte length
5. ERROR
- can be 0 byte length or contain an error string
6. GETFILE <filename>
7. DATA - x bytes indicating size + x bytes of data
Note: x can be 0. which means empty file!
A Sample Messaging
C - Client; S - Server
=============================================
C: LOGIN rajesh
S: NEEDAUTH aa1123
C: AUTH <Hash(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\"
Client closes the connection after receiving the DATA
and stores the data received into a file.
Extras/Optional: (Attempting will lead to Extra credit)
---------------------------------------------------------
Server side :
1. Server can timeout an idle connection, where the idle timeout can be
set as a command line argument.
2. Server can close the connection if client sends 'x' number of bad
GETFILE messages. 'x' can be made configurable.
3. Server side handling of BAD Clients sending
BAD/Invalid Messages/Out-of-Sequence Messages
eg. A Client connecting and trying to send GETFILE Message without sending LOGIN
4. Implementing a simple Server side log 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!
-4-
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 it 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. Take a download folder as a command line argument and
all downloaded files with unique names to be stored in this folder.
eg. if same file is downloaded twice, each filename will be unique
by suffixing it with a timestamp.
Note: As can be seen, the filesize in this barebones mechanism
is restricted to 2^32 bytes - 4GB as the length field is only 4 Bytes.
Extras (needs both server and client side co-operative changes)
- Ability to support better Authentication schemes.
- Ability to support big files on server side and client side
- Ability to support RANGE where the server can send 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 reads the file only the range requested
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.
"""]]

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