Creating an Instant Messenger

[Dee]

Is C++ the best language to create a Windows based Instant Messenger?

Something along the lines of MSN Messenger, ICQ, Yahoo Chat, etc?

Are there any downloadable full or trial SDK's out there?

I used to use Visual Basic a long time ago but want to create the
fastest, easiest for the end user to install, most reliable software
program possible

I certainly prefer the more visual approach to programming

[Phlip]

Dee wrote:

Is C++ the best language to create a Windows based Instant Messenger?
C++ is for big, hard, high-performance programs. A chat client is small,
easy, and low-performance.
Something along the lines of MSN Messenger, ICQ, Yahoo Chat, etc?

Are there any downloadable full or trial SDK's out there?
http://sf.net
I certainly prefer the more visual approach to programming

For the brief period of painting a dialog box for your client, you will get
visual. The rest is logical.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[Ioannis Vranos]

Dee wrote:

Is C++ the best language to create a Windows based Instant Messenger?

Something along the lines of MSN Messenger, ICQ, Yahoo Chat, etc?

I suppose all these were written in C++.

Are there any downloadable full or trial SDK's out there?

There are SDKs for interacting with these messengers. However I suppose if you want to
write your own messenger, this has nothing to do with these SDKs. What you will need to
know is networking and multithreading. Most network applications involve multithreading.

I used to use Visual Basic a long time ago but want to create the
fastest, easiest for the end user to install, most reliable software
program possible

I certainly prefer the more visual approach to programming

In VS 2003 and the upcoming VS 2005 all languages share the same Designer (RAD), so there
is no problem with that.

In fact myself am studying .NET networking these days, and what I am currently reading is
a sample network TCP chat client! This is two pages of code including the GUI code which
is automatically produced by the Designer. So we can say that it is relatively easy to
write your network chat client (at least under .NET).

However you will have to learn multithreading first, and this is somewhat demanding.


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Ioannis Vranos wrote:

In fact myself am studying .NET networking these days, and what I am
currently reading is a sample network TCP chat client! This is
about 4
pages
of code including the GUI code which is automatically produced by the
Designer. So we can say that it is relatively easy to write your network
chat client (at least under .NET).

However you will have to learn multithreading first, and this is
somewhat demanding.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Phlip]

Ioannis Vranos wrote:

In fact myself am studying .NET networking these days, and what I am
currently reading is a sample network TCP chat client! This is
about 4 pages
of code including the GUI code which is automatically produced by the
Designer. So we can say that it is relatively easy to write your network
chat client (at least under .NET).

However you will have to learn multithreading first, and this is
somewhat demanding.

I thought WinSock turned 'net input events into windows input events,
meaning you could write an event-driven chat client that needs no threads.

I also thought you could simulate WinSock by multiplexing socket handle
semaphores with your message queue.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[Ioannis Vranos]

Phlip wrote:

I thought WinSock turned 'net input events into windows input events,
meaning you could write an event-driven chat client that needs no threads.

I have to say that I am in the beginning of the networking chapter, so I know few things
so far. Also I do not know what exactly is the Winsock that you are talking about.
Naturally there are probably events for which we can assign member functions of our
classes as handlers, however not using multithreading implies that we are doing only one
task at a time. So for example upon sending a message (even in a matter of milliseconds
time), the client would not be able to receive a message or allow us to type. The same
upon receiving. And I suppose even when we are typing we will not be able to send or
receive (in console it is certain, since the program would wait until we press enter to
pass the input in cin and I suppose the same applies for GUI text boxes, since this is
also a type of input, and the typing itself raises events).
Perhaps you know more on this issue, what I have read so far is that networking "always"
involves multithreading (apart from some unusual cases I suppose).

I also thought you could simulate WinSock by multiplexing socket handle
semaphores with your message queue.

I don't know what exactly you are talking about. The fundamental class of .NET networking
is the Socket class which is considered the most low level part. However you never use
that class directly under usual circumstances, you use higher level classes that use the
Socket class, and their methods manipulate their underlying Socket objects.
So here is how you are making a client and connecting to a server instantly:
TcpClient *client= __gc new TcpClient;

client->Connect(serverAddress, serverPort);
It is nice, isn't it? :-)

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Phlip]

Ioannis Vranos wrote:

Also I do not know what exactly is the Winsock that you are talking about. .... Perhaps you know more on this issue, what I have read so far is that networking "always" involves multithreading (apart from some unusual cases I suppose).

By "event driven" I don't mean a .NET kernel calls events in our program.

I mean one takes apart the message sending and receiving protocol, down to
the byte level, such that temporary state, such as the position of the
file-pointer within an outgoing stream, are stored in object members, not in
local temporary variables. That allows you to write a top-level method
called, say, Pump(), that moves everything forward by one small increment,
then immediately returns.

Advanced 'net things need threads, when they are truly simplest. A

WinSock is MS's Berkeley Sockets implementation, invented during the Win16
single-threading era. It turns network events into windows events, so your
program only needs to block on and respond to window or network events. Such
an event would drop into our Pump() method.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces

[Phil Staite]

Dee wrote:

Is C++ the best language to create a Windows based Instant Messenger?

"Best" is a subjective term. Given the general requirements of your
typical chat client... I'd actually opt for Java - it has built in
threading and networking. A chat application doesn't need wildly high
performance so no worries there.

If you really want to use C++ (maybe as a learning experience?) then I'd
look at one of the rapid development environments. Maybe Borland C++
Builder and the Indy networking libraries. That combo would make
developing a chat client (and matching server) childs play.

[Ioannis Vranos]

Phlip wrote:

By "event driven" I don't mean a .NET kernel calls events in our program.

I mean one takes apart the message sending and receiving protocol, down to
the byte level, such that temporary state, such as the position of the
file-pointer within an outgoing stream, are stored in object members, not in
local temporary variables. That allows you to write a top-level method
called, say, Pump(), that moves everything forward by one small increment,
then immediately returns.

OK, I can't say much on these, since I do not know even enough .NET networking yet, as I
said in my previous message.
However the TcpClient and TcpServer classes use a NetworkStream object, which provides the
methods ReadByte() and Read() to read one and a sequence of bytes respectively and
WriteByte() and Write() to send one and a sequence of bytes respectively.
So to make your application connect to a server you do something like:

TcpClient *client= __gc new TcpClient;

client->Connect("www.mysite.com", 80);
NetworkStream *connection= client->GetStream();

// Receives a byte
int c= connection->ReadByte();
http://msdn.microsoft.com/library/de...dbytetopic.asp

http://msdn.microsoft.com/library/en...sreadtopic.asp
Advanced 'net things need threads, when they are truly simplest. A

WinSock is MS's Berkeley Sockets implementation, invented during the Win16
single-threading era. It turns network events into windows events, so your
program only needs to block on and respond to window or network events. Such
an event would drop into our Pump() method.

Well I do not know how things are done precisely in .NET yet. Perhaps we perform actions
like the byte receiving shown above, in event handlers. Perhaps tomorrow I will know a few
things more. :-)

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Ioannis Vranos]

Phil Staite wrote:

"Best" is a subjective term. Given the general requirements of your
typical chat client... I'd actually opt for Java - it has built in
threading and networking. A chat application doesn't need wildly high
performance so no worries there.

If you really want to use C++ (maybe as a learning experience?) then I'd
look at one of the rapid development environments. Maybe Borland C++
Builder and the Indy networking libraries. That combo would make
developing a chat client (and matching server) childs play.

I do not want to look like as not providing any other language option than C++, however I
can not see what advantage any other language such as Java, VB, C# or whatever would have
in comparison to C++.
A C++ developer can have whatever he needs for rapid development. For example have you
tried the latest VC++ lately?


--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Phlip]

Ioannis Vranos wrote:

Phlip wrote:

By "event driven" I don't mean a .NET kernel calls events in our program.
I mean one takes apart the message sending and receiving protocol, down to the byte level, such that temporary state, such as the position of the
file-pointer within an outgoing stream, are stored in object members, not in local temporary variables. That allows you to write a top-level method
called, say, Pump(), that moves everything forward by one small increment, then immediately returns.

OK, I can't say much on these, since I do not know even enough .NET

networking yet, as I said in my previous message.
Nothing I wrote has anything to do with .NET.
int c= connection->ReadByte();

Right here, there are two ways to get a string. You can loop, or you can
treat the input as an event.

This is not a .NET magic object Event - it's just an event. If you loop,
then you will block inside the loop. That leads some to think you must use
threads to chat.

If, instead, you treat inputs as an event, then you can block in one
thread - the same one that blocks for your windows events.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces