Prev: Undo in a webbrowser
Next: Concurrent access to private data
From: Anders Eriksson on 27 Apr 2010 04:39
Hello,

I need to create a program that communicates with three different TCP/IP
servers. The servers have totally different protocols. The communication has
to be concurrent.

I understand that I need to use Multi-threading but that is something I
haven't done before.
So I need some starting points.

// Anders
--
English is not my first language
so any error, insults or strangeness
has happend during the translation.
Please correct my English so that I
may become better at it!

From: Mr. Arnold on 27 Apr 2010 04:57
Anders Eriksson wrote:
> Hello,
>
> I need to create a program that communicates with three different TCP/IP
> servers. The servers have totally different protocols. The communication
> has to be concurrent.

What do you mean different protocols? I see only one protocol mentioned
here TCP/IP. In addition, is not the service program you're talking
about communicating with 3 different client programs running on remote
machines?
>
> I understand that I need to use Multi-threading but that is something I
> haven't done before.

What you needed to use is a Windows Communication Foundation service
program using TCP/IP with 3 different end-points hosted by a machine,
and WCF client programs running on 3 remote machines each with their own
service end-point doing unique processing with each client concurrently.
From: Peter Duniho on 27 Apr 2010 05:25
Anders Eriksson wrote:
> Hello,
>
> I need to create a program that communicates with three different TCP/IP
> servers. The servers have totally different protocols. The communication
> has to be concurrent.
>
> I understand that I need to use Multi-threading but that is something I
> haven't done before.
> So I need some starting points.

Actually, it's not true that you _must_ use multi-threading. However, I
would agree that using mulit-threading is the simplest approach, in
spite of the underlying added complexity multi-threading introduces.

First, note that the question of the protocols in use is irrelevant.
The same issues exist whether you have three different connections all
using the same protocol, or three different connections all using
different protocols. For that matter, even if you're talking about
using UDP (i.e. there's no connection), the same basic issues exist.

You can use the Socket.Select() method to manage more than one socket in
a single thread. That's what I mean by saying that it's not true that
you must use multi-threading.

But, Socket.Select() doesn't scale well and IMHO it makes the code more
complicated.

As far as a multi-threaded solution goes, if you know you will only ever
have the three connections (I use the term "connection" loosely, simply
to describe a socket instance representing the local end of some logical
relationship between your code and the remote endpoint�this includes
UDP-based protocols), then simply dedicating a single thread to each
connection is the simplest way to implement your program.

If you want to be able to deal with arbitrarily many connections, then
using the asynchronous API is best. Personally, I find the API simpler
as well, than for example using dedicated threads for each socket, but
that's just me. I know lots of people who don't and prefer the
dedicated thread route where feasible, and that's fine. Use what fits
your mental model the best, worry about performance only when it is
proven to be an issue worth worrying about.

Note that the Socket class actually has two asynchronous APIs. The
Socket.Begin/EndSend() and Socket.Begin/EndReceive() methods is the
simpler of the two, and is actually quite efficient relative to most
other choices. But there's a newer asynchronous API, the methods that
end with "�Async", that is even more efficient because it allows reuse
of the async objects, minimizing impact of resource management on the
network i/o throughput.

Most applications don't need to base the design choice on performance;
in those cases, it's really just a matter of picking the API that is the
easiest and simplest for you to implement and maintain.

So, those are your options, specific to the socket API. Of course, if
you choose any of the approaches that do involve multi-threading, then
you will have to become familiar with the more general realm of
multi-threaded code, which is a major topic all on its own. The short
version is: synchronize all state that is shared between two or more
threads; to synchronize, use the "lock" statement around any code that
has to modify more than a single 32-bit value at once; use "volatile"
for any 32-bit variables that can be modified independently of anything
else (i.e. the state of which is not in any way correlated to anything
else); and if there's a GUI involved, use the appropriate method to
access GUI objects from non-GUI threads (e.g. the Control.Invoke()
method for a Forms application).

If you need more multi-threading information than that, it is probably
best that you learn about multi-threading in a simpler setting than
trying to get a socket-based network i/o implementation to work.

Pete
 | 
Pages: 1
Prev: Undo in a webbrowser
Next: Concurrent access to private data