making chat client...

[WhorlyWhelk]

Never done it before,, looking for some simple guidance where to start.
Is this a good application of posix threads? I am thinking maybe I should I have 1 thread reading from the socket continually to get updated info from server, and 1 thread that takes input and then writes to the socket only. Maybe I would have a third thread to redraw the output screen every time it was updated.

[JetSnaiL]

Hello WhorlyWhelk,

I remember old ninetieth when IRC chats were very popular and every single student had its own robot implementation pretending to be AI. It is nice to know that tradition is still alive!

That being said, here is what I think is the best way to go. Step by step.

First of all, forget about POSIX threads. You won’t need asynchronous thread cancellation, detached threads or signal processing masks for your robot. In other words - nothing specific. At the same time, you need clear and simple interface to work with threads. For that purpose I would highly recommend looking at Boost Threads library. It is designed from the ground up to be easy to use and cross-platform. So you don’t need to have millions of “ifdefs” in your code for each platform. You can read more about this magic beautiful library at http://www.boost.org/doc/libs/1_40_0/doc/html/thread.html

Now, when you have all you need to create threads and parallel your application, let’s talk about networking. I am sure that you need to connect to some server using TCP/IP or UDP, don’t you? There are multiple ways of doing this. First of all, you have to decide whether you need synchronous or asynchronous I/O. Basically, synchronous I/O means that when you are calling “read” or “write”, your application is blocked until that call completes. What a waste of time! Why not to process logs, write some matched sentences into the database or simply render nice GUI while that “read” or “write” operation is in progress? If you agree, then you need asynchronous I/O. The downside is that it is extremely hard to code yourself. All these system calls are different on each platform. Frankly, same calls does not always behave identically. But.. but... there is a nice object-oriented, cross-platform C++ library designed especially for this purpose. It is called ASIO (stands for ASynchronous Input Output), recently it became a part of Boost C++ Libraries. There is a good documentation and lots of simple examples to get you started as quickly as possible. Here: http://www.boost.org/doc/libs/1_40_0/doc/html/boost_asio.html

Having those two beasts incorporated in your project, you can write extremely fast and scalable char client. You can make it single threaded or multi-threaded, easily scale it across CPUs etc. Working with threads should be scalable. You don’t have to think how many threads do you need to write to the socket or to read from it. This should be very scalable. I would even say that it should be possible to change by modifying program’s configuration. With Asio, you simply need to call its “service” class method in each thread to make it utilize them all.

As for the GUI, you should not create a separate thread. All modern GUI frameworks has its own thread which often called a “dispatching thread”. When some data arrives on the socket, you need to process it and then post event to the GUI dispatching thread to be processed in the same context as all other GUI events. In QT, for example, this operation is called “emit”. It emits a signal that is passed to GUI’s tread. It is as simple as calling a function and all threading/queuing work is done by the framework.

Hope this is helpful. Don’t hesitate to ask should you have any questions.

Good luck,
Vlad

[Orum]

I've written a p2p chat app (though a little different than most), and here's what I've learned. This is a little more general than what JetSnaiL is talking about, so I hope it proves useful.

1) What will your chat program do that others don't? There's already a lot of clients (e.g. Pidgin) for common chat systems out there (XMPP, AIM, ICQ, etc.).
2) What protocol or protocols will your client support, and why? Are you going to design your own protocol, and if so, why? If you are designing your own protocol, are you willing to document it so other people can write compatible messengers?
3) What platforms are you planning to write it for? Are you willing to port it to others? If you want a messenger to be adapted, it needs to work on several platforms, or at least encourage development on other platforms through open, unambiguous, and concise protocol documentation.
4) If you're going to make it cross platform, are you going to use cross platform libraries, or port it manually? If you're using cross platform libs, which one will you use for the GUI? Which one for network I/O? What about the server? What performance is needed, and will your lib support it?

Consider all of these things carefully before you write a network messenger. I know I changed some design goals after I already had a working messenger, and it has cost me a lot of time rewriting code. However, the experience of designing and writing a messenger encompasses so much, even if it's not adopted you will learn more than you ever wanted to about the OS's API or the libraries that you're using. It also gives you a good understanding of the pro's and con's of various options for protocol design, even if you're just implementing an already defined protocol.

[JetSnaiL]

Orum, you are too conservative. What if he wants to play with C++, writing something from scratch just for fun? It is much funnier than trying to understand someone else's code.