C# Chat Application Push technology

[TotoTitus]

Hello everyone,
I need some advice.

I have been given an assignment to construct some kind of chat application which uses push technology (In C#, so i have socket objects and all that)
Reading on the internet, i came to know that push technology means in essence, that not the client makes requests, but the server updates content when 'it thinks it's appropriate' (mostly on a time-based schedule, or as soon as new data arrives).
Now i need a few ideas an hints, from you guys who are more knowledgeable in this domain.
My main questions arise here:
If a client logs in, and starts chatting with another one, a regular messenger client would open a connection to the other client, essentially making it a Peer2Peer mini-application, with no server interference. The only actual role of the server would be to update the list of contacts as they 'log in' and 'log out'.
Is this particular implementation good? How do other messenger-chat-apps work? Shouldn't the information pass through the server? If the server's only role is to announce who is 'logged in' and 'logged off', then why bother implementing push technology? (I've been given the assignment, with the words 'push technology' stressed out).
Also some advice regarding socket implementation / problems encountered is appreciated.

Looking forward to hearing your answers.
Thank you.

[kvprajapati]

Have a look at this blog.

[TotoTitus]

Good article, but i still need more info about push technology (which is not so-easily-available on Google...well anyway it's better receiving a straight answer on a forum)

[Diamonddrake]

I have never heard the term "Push Tech" but To my knowledge most chat applications go through the server for everything. But there is a possible peer to peer relationship that can be established.

Normally. The client messengers contact the server. the server has a thread pool of sockets blocking waiting to accept new client connections. Then once the handshake is made, the socket with the client connection is passed to a thread pool for redirecting messages. And the client's login name is added to a list. Then when a client sends a message to another client. It actualy is sending the message to the server like"attention:client name: message" the server then write that message to the socket for that intended client. The client has a thread constantly blocking on a socket read waiting for new mesagges. once it gets one it shows it to the user and goes back to blocking on a socket read. and the gui thread is always open to write outgoing messages or update the display.

now in a server logged peer2peer situation, Clients connect to a server just to tell the server where they are, who they are, and what they can do, and get a list of that information about other logged in clients. So then each client has the information it needs to make a direct connection to other clients. But this requires ports to be opened and other hassles. But it keeps the load off the server, so a small server can provide for many clients.

There are TONS of examples online of how to make chat applications. It doesn't really take 20 minutes to write a real world usable chat server and client in .net.

Have fun with it. I know I did.

[TotoTitus]

Thank you. Will post here if within the process i encounter some special problems.

[TotoTitus]

I've just come over another thing: My application should handle ~10.000 connections at the same time, and i've read that TcpListener / TcpClient, while providing a higher level of abstraction, are 'slower' than the simple base Socket class. Is this true? Should i use a Tcplistener for the server, and socket objects for clients ?

[Diamonddrake]

The wrapper classes are technically slower than the base socket class. But if you need the functionality of them you will end up building your own wrapper for the base socket class that will likely have its own performance drawbacks.

So its not exactly a simple question. Best I can advise it to research other programmers results and see what combination of techniques best serves your purpose.

[TotoTitus]

I've done some few hours of work, i came up with this...but for some reason it ain't working...
I've made two separate projects for the client and server: They should be able to communicate with each other, but they aren't.

[Diamonddrake]

Well for starters you are using 2 separate stream objects, and using them quite oddly.

you should just be using 1 NetworkStream object instead of your stream reader and writer objects. NetworkStream clientstream = client.GetStream() This will allow you to read and write to the network with one object and its also important that you always write Bytes to the stream. you can't just write text to the stream you need to convert the text to a byte array in a buffer and send it in chunks. small strings it doesn't matter much. But if it were an entire paragraph you aren't going to get 1 to 1 writes and reads.

But none of that really matters. It doesn't work because your two application use DIFFERENT PORTS! your client is trying to connect to port 1000 while your server is listening on port 4296. Change the port in the connect method of the client app to match the listener on the server and you should be good to go. assuming that you have your ports forwarded on your network, unless of course you use local host.

Also your threading is kinda sketchy, but it should work. that application.doevents() appears to be used in an odd fashion. See what you can do with the information i have given you. If you can't get it working right I will go back and edit the projects and re-post them. I would have already done that. But you are doing a great job and its so much more empowering to figure it out yourself with a little nudge. That and I'm kinda busy at the moment. i just wanted to stop by and participate in the world as I do from time to time.

[TotoTitus]

Alright, i've made the client-server thing work, i mean they can communicate.
But i've been thinking how to make stuff work on a larger scale, and i've come with this idea:
Every client employs one UDP socket and one TCP socket. The TCP socket is used to communicate with the server(stable connection) and the UDP socket is used to communicate with everyone else. The server would handle only logon/logoff messages transmitted between the clients, and everything else would be handled by the UDP sockets.
I've made this small application (in the final stage, the IP list would be supplied by the server, for now you have to add the IP's yourself). Some sort of communication is going on, but when i try to communicate with myself (127.0.0.1) the whole thing freezes ( a form is created form each private chat ) .
I need some guidelines on this one, especially on threading issues.
Thanks !

[sknake]

Out of curiosity have you read the WCF/WPF Chatter codeproject article?
http://www.codeproject.com/KB/WCF/WCFWPFChat.aspx

You could use WCF to generate proxy clients that will handle threading for you by applying attributes on the contract implementation. There is also a "workaround" for using shared assemblies (instead of proxies) and having .NET handle the threading for you:
http://ayende.com/Blog/archive/2008/03/29/WCF-Async-without-proxies.aspx

I have also read over this thread and i'm not seeing a compelling reason for deciding on p2p, nor why you would use UDP over TCP. Usually UDP is used for RTP (real time protocols) such as video streaming or voice streaming. UDP does not ensure data delivery so if packets are lost -- then transmissions are lost, meaning a crackle in the phone or missed updates on your video player. With TCP they would "catch up" and replay the missed media (undesired). With text-based chat I believe you want to ensure the message was transmitted properly. You also run in to numerous issues with firewalls etc etc when using a p2p approach. Take a look at the IRC protocol.

[TotoTitus]

Alright, i'll try to go on. But the reason i tried going UDP is that i read somewhere on codeproject that TCP generates a lot of overhead, and that connectionless transmitting of data is very efficient.
Erm...as a response to you first link....i'll try to study it (i already looked at it) but hey, it's huge !. Maybe it sounds stupid, but can't i make a working-with-minimum features app with only ~300-500 lines of code? (not that i wouldn't write more, but i want to know exactly what i'm plunging into). thnks.

[Diamonddrake]

interesting article sknake, but titus i can agree that its a LOT of code. I wouldn't worry about the overhead of a TCP socket, Each user isn't going to have 120 open convertsations. As sknake pointed out, UDP is best used for live streams like audio. If you were to add a skype feature to your chat app. you would certainly want that p2p UDP connection. But just for text. TCP is best.

Using the P2P system you are pointing out would put significantly less stress on the server. But the question here is, are you planning to have 20,000 users? If not, having the server handle everything would be fine, assuming you created a nice thread pool that would cycle through pending messages and deploy them.

Its always nice to have your tools handle the trouble spots for you. like apps that generate objects based on xml schemas and tools that create asynchronous methods from a class or even compiled code. But it doesn't hurt when in a learning environment to try and do it by hand, just so you really know what's going on, how it works, and why it there.

Regardless, no matter how neat it is to make a chat application, unless you really feel like you can compete with Yahoo, Aim, MSNMessenger, Trillian, and Pidgin. Then its just a learning experience anyways. In which case, dive in and make mistakes that you learn from.