Common bugs and some suggestions: Project 1

  1. Byte ordering problems: Some of the submissions did not perform byte-ordering and some of them ordered the bytes incorrectly. In the former case, the students' submission would not work with itself across platforms, and in the latter, it wouldn't work with a correct implementation (ie. one that orders bytes in big-endian format). Note that use of htons/ntohs would do the job for you. It is also likely that these bugs went unnoticed because you did not test it on both x86 and sparc. FYI, rhombus and torus are x86 machines, nova, pulsar, star are sparc.
  2. Your program must be single threaded. You must not use fork() or pthreads. If you do so, you may not receive much credit.
  3. The value of the length field should include the size of the length field and type field also.
  4. In the specification, when we say <username>, we mean that you have to print the username. You should not include < and >. For eg., when a new client with name John joins, the server should print 'join: John'.
  5. You are not supposed to hard-code the ports/addresses/usernames. They should be accepted as command-line arguments. Refer to the first page of specs (Usage of chatserver and chatclient) for details.
  6. If a user disconnects from the server, all relevant state must be removed cleanly. An immediate attempt to connect to the server with the same user name must succeed.
  7. Client must shutdown gracefully when the server dies. The server/client must check for return value of select() and close the connection if the other end has closed it.
  8. Note that the specs clearly states that the username does not include the '\0' at the end. Also, '\0' should not be taken into account for calculating the length of the name.
  9. If the program does not compile, we tried to compile it and give partial credit to the extent possible. However, this would not be done in the final version.
  10. Read the specifications carefully. Your output in the final submission must conform to the specifications.
  11. If you are printing anything other than what is specified, it must go to stderr. Do not print the statements that you have added for debugging into stdout.
  12. Fill in the README.
  13. Be careful to submit all the files needed.
  14. We also noticed general programming errors/bad practices such as writing functions (ie full code for the function) in header files, poorly structured/commented code.