Telematica: report is finished.

parent 47fe6b01
...@@ -46,3 +46,15 @@ text-based user interface of the client. ...@@ -46,3 +46,15 @@ text-based user interface of the client.
.. [3] curses -- Terminal handling for character-cell displays: .. [3] curses -- Terminal handling for character-cell displays:
http://docs.python.org/library/curses.html. http://docs.python.org/library/curses.html.
Protocol specification
----------------------
The instructions of this assignment required that the client and server should
communication according to a given protocol. The protocol [4]_ is not further
discussed in this report, since the protocol is described clearly and it would
be redundant to add it to the report.
.. [4] Client / server protocol:
http://staff.science.uva.nl/~mlankamp/2011/Telematica/protocol.desc
...@@ -198,11 +198,23 @@ We implemented the following commands: ...@@ -198,11 +198,23 @@ We implemented the following commands:
Server side Server side
---------- ----------
Multiple client handling
~~~~~~~~~~~~~~~~~~~~~~~~
The class *Server* accepts the incoming connections from clients and initialises The class *Server* accepts the incoming connections from clients and initialises
a request handler (see class *RequestHandler*) for each accepted connection. The a request handler (see class *RequestHandler*) for each accepted connection. The
servers logs all its information, warnings and errors to stdout. To change the servers logs all its information, warnings and errors to stdout. To change the
behaviour of the server log, alter the configuration file *logging.conf*. behaviour of the server log, alter the configuration file *logging.conf*.
In order to create a list of currently active users, we used an dictionary based
on the client's address tuple (ip address, port). To check if a user does not
take the nickname of an existing user, we simply iterate over the list of active
users and compare the name of each user with the requested nickname. If it
exists, return a negative response, otherwise if the nickname is valid according
to the protocol, return a positive response. It is possible to build an index
for the name lookup, but that optimization is not worth it as long as there
aren't many clients connected. And if there are many clients connected, there
are more important scalability problems to solve (e.g. better socket
multiplexing, synchronisation between different server and load balancing).
Compared to the client (and its interface), the server is very simplistic. This
is on purpose, because we wanted to create a server which does exactly what is
required in the protocol specification. In this case, less is more.
...@@ -190,8 +190,7 @@ class RequestHandler(AsyncBase, asyncore.dispatcher): ...@@ -190,8 +190,7 @@ class RequestHandler(AsyncBase, asyncore.dispatcher):
# already taken. If the name is valid, notify the other clients. # already taken. If the name is valid, notify the other clients.
name = buf[5:] name = buf[5:]
for c in self.server.clients: for c in self.server.clients:
if self.server.clients[c].username == name \ if self.server.clients[c].username == name:
and self.server.clients[c].handler != self:
return self.send_negative('Username already taken.') return self.send_negative('Username already taken.')
if re.match(ur'^[^\u0000-\u001f\u007f-\u009f/:]+$', name): if re.match(ur'^[^\u0000-\u001f\u007f-\u009f/:]+$', name):
if not self.username: if not self.username:
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment