just like in IRC, we have the notion of "channels". Each channel is going to have 2-5 clients registered. A message from any client is multicasted to other clients on the same channel
support several channels without authentication. Clients should know which channel they want to use ahead of time (we just hardwire them) and notify the server using an argument in their POST request. E.g. clients 1/2 will ask for channel "c1", clients 3/4/5 will ask for channel "c2" and server will do multicast appropriately. Note that without authentication and with the clients continually reminding the server of their channel, this is pretty simple - no database involved and no need for cookies, IP tracking etc.
write the client app for the test that can run on the desktop
test the ability of the server-client setup to maintain relevant responsiveness for a small number of clients. E.g. if we have just 4 clients on 2 channels, at least you should verify that we can send 70 bytes every 4 seconds from each one and get them on the other clients within small latency. In other words - the basic goal of the communication has been accomplished, and we are not just trying to make a worse version of the heavily throttled Yahoo IM :-)
ideally, you should also develop, teach me, and carry out a more thorough test of the same system involving several thousands of simultaneous clients. Unfortunately, I don't know off the top of my head how to do that. So I hope you will figure it out and do it either as part of the initial project or at least we will plan it for the next project.