Can any one guide me a simple design or idea or common steps to implement UDP Chat server and Client?i am not asking cord ,i want to try my self.I am looking for a programming language independent explanation.
Thanks in advance
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Can any one guide me a simple design or idea or common steps to implement UDP Chat server and Client?i am not asking cord ,i want to try my self.I am looking for a programming language independent explanation.
Thanks in advance
The classic design is, whenever a user types a line of text into his chat-client, that client puts the text (and possibly some other info, such as the user’s name) into a UDP packet which it sends to the server. The server receives the UDP packet, and then forwards copies of the packet onwards to all of the other clients it knows about. When the other clients receive the forwarded packet, they each display the packet’s contents for their local user to read.
The only non-obvious part is discovery — i.e. how does a client know which IP address to send the UDP packets to, and how does the server know which IP addresses to forward received packets on to?
If you can guarantee that all the clients will always be on the same Ethernet LAN as the server, then this is easy to handle — just always send all UDP packets to the broadcast address (255.255.255.255), and everyone on the LAN will receive them. (In fact, in this scenario you don’t need a server at all, as the clients can communicate with each other directly).
In the more realistic case where clients are located at arbitrary locations on the Internet, discovery gets a bit more difficult. Hopefully you can run the server at a well-known, fixed location (e.g. http://www.thabo-chat.com or something) and just hard-code that hostname into the clients. Then whenever a client starts up, it can send a UDP packet to the server to let the server know that it exists, and the server can read the source IP address from the received UDP packet and add it to a list of known-client-IP-addresses that it will forward received packets to. It should also keep a timestamp of when each client was most recently heard from, and remove IP addresses from the list if they haven’t been heard from in a long time (to avoid pointlessly sending packets to clients that have since gone away).
The last issue you’ll face when using UDP over the Internet is that a lot of computers out there are behind firewalls that will block UDP packets coming from the Internet, so the UDP packets your server sends will in many cases not arrive at the clients it was trying to send them to. There’s not a very good solution for this — you can ask your client-users to set up UDP port-forwarding on their router, but that’s a hassle for them and a lot of people don’t have the skills to do that. The only real alternative in that case is to use TCP instead, and have the clients connect to the server via TCP and send data back and forth that way instead (that way works because almost all firewalls allow bi-directional data traffic over outgoing TCP connections, since that is necessary for web browsing and email)