Introduction

The original article proposed to demonstrate elementary network programming
by designing a very simple SMTP server class. It had no support for sending
attachments and was quite uncomplicated in nature. Since there are much better
classes available within the BCL for sending emails, the exercise seemed to be
quite futile. Therefore I have updated the article so that it provides a decent
introduction to network programming. There are already several introductions to
network programming on the web and I wanted this to be slightly different from
all of them. Whether I was successful in that endeavor is up to the end-readers
to judge.

Basically with the advent of .NET, remoting and web services are the
preferred means of network communication. Both mechanisms are object oriented
and allows the programmer to work from a high level of abstraction. But there
are often situations, where you might want to communicate with native programs
that were written prior to .NET, or for some reason you cannot expect all
clients to be running .NET enabled programs. That's where we can use the
slightly lower level network classes for our network-based programs. There is a
Socket class available but I prefer to use the TcpListener and
TcpClient classes which offer a higher level of abstraction.

In this article we'll design a multi-threaded TCP server using Managed C++.
This server is very simple in functionality. It accepts a line of text and
returns the reversed version of the same. We'll write an MFC dialog based
application that will use the MFC CSocket class to chat with our Managed C++ TCP
server. Since we have used basic TCP protocol, it does not matter what language
the client program is written in. Just to complete the wheel, I also include a
Managed C++ version of the TCP client, which also serves to demonstrate the
TcpClient class.

TCP server - MC++

We write two classes here - SpookServer which basically starts
our TCP server and listens for connections, and SpookClient which
is a class for handling individual client connections. The SpookServer
class itself spawns off a new thread in which it waits for connections. And for
each connection, it instantiates a SpookClient object which
immediately spawns off a new thread to handle the particular client connection.
This system of one thread per client is quite acceptable in our case because
each TCP chat involves so little process flow. It's just a matter of accepting a
line of text, reversing it and sending it back.

Well, the class is rather simple, but I'll still give a quick run-through of
how it works. We use a ManualResetEvent object for synchronization.
This is basically so that the calling class or method has a means of stopping
the server anytime, in our case this is _tmain. As you can see, we
spawn off a new thread where we listen for connections. This is so that we can
return control to the calling class. We use the AcceptTcpClient
method of the TcpListener class which returns a TcpClient
object that is a reference to the connected client. Immediately we instantiate a
new SpookClient object passing the returned TcpClient
object to it's constructor. And we go back to AcceptTcpClient, thus allowing a
seemingly innumerable number of clients to be able to connect at any one time.

The SpookClient class has a TcpClient member and we
assign the TcpClient object passed to the constructor to this
member object. And we start off a new thread. Inside the thread, we first call
TcpClient.GetStream to get the underlying NetworkStream
object. Once we have the NetworkStream object we can use Write and
Read on it to send and receive data, respectively. We simply accept a line of
text, by looping till a \n is encountered and then we reverse it
and send it back. Remember to Flush and Close the
NetworkStream object and then call Close on the

Well, we don't do anything spectacular here. We simply send the text using
CSocket::Send() and receive back the reversed line of text using
CSocket::Receive. You'd think that with using network streams and
all, the data would have been slightly personalized for .NET purposes, but
apparently the raw data is preserved. This indicates that you can use the

TcpListener

and TcpClient classes for any kind of Tcp
programming including popular protocols like HTTP, SMTP, POP3 etc.

I have written another class here called SpookClient, not to be
confused with the other class in the server program that has the same name. This
uses a TcpClient object to connect to the server, gets the
underlying NetworkStream using GetStream and uses
Write and Read for sending and receiving data, to and
from the server. This code snippet would look very similar to our client handler
class in the server program because they both demonstrate the use of the

NetworkStream

class.

License

Share

About the Author

Nish Nishant is a Principal Software Architect based out of Columbus, Ohio. He has over 17 years of software industry experience in various roles including Lead Software Architect, Principal Software Engineer, and Product Manager. Nish was a Microsoft Visual C++ MVP between 2002 and 2015.

Nish is an industry acknowledged expert in the Microsoft technology stack. He authored C++/CLI in Action for Manning Publications in 2005, and had previously co-authored Extending MFC Applications with the .NET Framework for Addison Wesley in 2003. In addition, he has over 140 published technology articles on CodeProject.com and another 250+ blog articles on his WordPress blog. Nish is vastly experienced in team management, mentoring teams, and directing all stages of software development.

Contact Nish : If you are interested in hiring Nish as a consultant, you can reach him via his google email id voidnish.

Comments and Discussions

Hi, I took the liberty I hope i had and converted the code for the MC++ server and client so one did not have to use the /clr:oldSyntax (insteed using /Clr). I also made it so the server listend on port 2302 (I just did it because it was the port my program was using atm. :smile: ). I also made the client able to choose the IP to connect to. I think thats all the major stuff i changed at least .

MC++ Server
<code>
#include "stdafx.h"

#using &lt;mscorlib.dll&gt;
#using &lt;System.dll&gt;

#include &lt;tchar.h&gt;
#include &lt;conio.h&gt;

using namespace System;
using namespace System::Net::Sockets;
using namespace System::Threading;
using namespace System::Text;

As you can probably see i used Visual Studio (2005)...
I have the project file for this but i cant figure out a way to link to them!
So just replace the code in TcpServerDemo and TcpClientDemo from the download on the page with the above code! ALSO: Remember to remove the /clr:oldSyntax and replace it with /Clr!

I'm Sorry, I MIGHT write an artical and put in the project files, until then do the above... it should work.

Actually i am facing a problem with my socket client that its running fine on my development machine , but when I have transfer it to some other machine on the same network, client connects fine but when I send request for the data CSOcket->RECEIVE function returns -1.

SeanV wrote:How about creating a Java Client for the MS Chatter Example

For mostly whimsical reasons I have always stayed away from Java and it has only done me good so far. Therefore I am wholly unsuitable for writing anything in Java. Perhaps someone else can do this (it shouldn't be too difficult I guess)

Nish

"I'm a bit bored at the moment so I'm thinking about writing a new programming language" - Colin Davies

I have a MFC activity which "loads" data through several "edit boxes" generated by the MFC "Wizard" to create a screen for input. Each time I execute the application, I can input my data, using an Updatedata(TRUE) statement after each input to get the data transfered. However, when I call a C++ program from the Dialog application with the input values to get the equation for the curve that "goes" through all of the points, I then want to return to the original screen and "click" on another button on the screen to plot the output. The problem is, when the return from the C++ subroutine is made, the system stops execution. What do I have to add to the dialog program to continue to plot(in another window?)? Please let me know at s.w.kraft@netzero.net. Thanks in advance, Sid Kraft.

211 System status, or system help reply
214 Help message
(Information on how to use the receiver or the meaning of a
particular non-standard command; this reply is useful only
to the human user)
220 <domain> Service ready
221 <domain> Service closing transmission channel
421 <domain> Service not available, closing transmission channel
(This may be a reply to any command if the service knows it
must shut down)

If you take a look, it handles the relative error messages.
SMTP is funny old protocol, bent and twisted over the years. I built the class because IIS SMTP service (which the .Net BCL mail classes rely on) is not sufficient for some applications. For example - I used to work for an ISP where we authenticated users from a DB. IIS SMTP cannot do this.