Name: Taylor Hardy
Email Address: thardy30@gatech.edu
Class name: CS 3251 (Computer Networking I Fall 2016)
Class section: A
Date: 10/2/2016
Assignment title: Sockets Programming Assignment 1
Files:
sensor-server-tcp.py Server for TCP
sensor-server-udp.py Server for UDP
sensor-tcp.py Client for TCP
sensor-udp.py Client for UDP
passwords.csv a CSV file containing logins for a server
README this file - information about files, usage, and protocol
TCPtest.sh Bash script for testing TCP client
UDPtest.sh Bash script for testing UDP client
TCPresults Results of running TCPtest.sh
TCPserverresults Server output from running TCPtest.sh
UDPresults Results of running UDPtest.sh
UDPserverresults Server output from running UDPtest.sh
usage: (the --help or -h provides further help) (all arguments are required unless otherwise specified)
run the server (sensor-server-tcp.py or sensor-server-udp.py)
before running the corresponding client (sensor-tcp.py or sensor-udp.py
sensor-tcp.py:
python sensor-tcp.py -s [server address] -p [port] -u [username] -c [password] -r [value]
sensor-server-tcp.py:
python sensor-server-tcp.py -f [passwords.csv] -p [port] (optional -v for verbose mode)
sensor-udp.py
python sensor-udp.py -s [server address] -p [port] -u [username] -c [password] -r [value]
sensor-server-udp.py:
python sensor-server-udp.py -f [passwords.csv] -p [port] (optional -v for verbose mode)
~~Protocol~~
note: \n represents a newline present in the protocol. Newline whitespace in documentation is only there for cosmetic puposes
Message Format:
fields are delimited by a newline.
Every message ends with a newline.
Message skeleton:
[message type]\n
[data]\n
Message Types:
REQC: authentication request (REQuest Challenge)
format:
REQC\n
CHAL: CHALlenge value
format:
CHAL\n
[64 character challenge value]\n
AUTH: AUTHentication information
format:
AUTH\n
[username]\n
[md5 hash of password]\n
ARES: Authentication RESult
format:
ARES\n
[result of authentication (True or False)]\n
DATA: sensor DATA
format:
DATA\n
[sensor value]\n
FIND: FINal Data
format:
FIND\n
[username]\n
[last recorded value]\n
[time]\n
[sensor Min]\n
[sensor Avg]\n
[sensor Max]\n
[All Sensor Avg]\n
Protocol Order:
sensor -> server: REQC
server -> sensor: CHAL
sensor -> server: AUTH
server -> sensor: ARES
sensor -> server: DATA
server -> sensor: FIND
Known errors/limitations:
if a value is sufficiently large (larger than about 256 bytes) it could overflow the receive buffer, causing it to be cut off or bad things to happen
Since md5s are stripped of \n when compared, there could possibly be a situation where an incorrect password is accepted, although the likelihood of this happening is extremely low
In UDP, connection will time out after 20 failed tries to contact a server in a row
In UDP, if client fails to receive FIND it could try to send the DATA again which could result in bad things (or could be harmless, UDP wont drop any packets in my tests with docker)