Communication between clients

[Heinz Grandjean]

Many thanks, gentlemen, for Your help.

I think, I should go further on the bridging path.
Having the clients equipped with an asynchronic-listening window
and having all connections open until the server terminates the arrangement works.
The only problem is the lack of a good theoretical handbook concerning these questions, that is not -as always- a hidden tutorial about C++!

Thanks again
Heinz Grandjean

[Erich Schulman]

My question: would it be possible to have two clients (!) getting in contact with each other using this multithreaded server as (let us say) a brigde??

That is how services like LogMeIn and GoToMyPC work. You get the added advantage that dynamic IPs are taken care of for you. Your client tells the server which remote client you want to talk to, and you don't have to know the remote client's IP.

You can also have a many-to-many relationship without a central server (think BitTorrent). But in this situation, you do have to deal with firewall issues.

[Michael Mattias]

In re the fundamental question...

Or do I missunderstand TCP??

..no, you don't. TCP may be used to engage in "conversations" using the Internet as the carrier. Basically as soon as you have IP addresses or URLs, you can do all kinds of stuff using many different methods.

However, I agree with the business-soundness (and maintenance-soundness!) of a design which features a single server as a 'traffic cop.'

I would probably agree with the 'security-soundness', too, but I don't do security.

[Mike Stefanik]

But if they were, why even keep the server in the loop as a "bridge" when the two clients can connect and talk directly?

One practical reason is firewalls. In a corporate environment, desktop clients tend to have restrictive firewall policies where they're only permitted outbound connections, sometimes within a limited port range. Joe User running a server of any stripe (any application that listens for inbound TCP connections) on his desktop is something that most companies simply will not allow. Using a server as the middleman between the clients, routing the messages and notifying clients when new messages arrive is generally the most flexible and firewall-safe approach to take.

It can also address security and permissions related issues; since all messages must pass through the server, it can monitor and filter them as appropriate. For example, the server can have code that looks for clients who are sending a high volume of messages and throttle them, preventing other clients from getting swamped (or preventing an outright denial-of-service attack). It also allows for a centralized authentication and policy mechanism, rather than having each client being responsible for determining if another client should be allowed to talk to it, and what kind of messages they should be able to send.

[Michael Mattias]

Why not?

Client to server: "I'm here"

Server to Client: "Cool. Here's who else is here: Name/IPAddress, Name/IPAddress ...."

However, clients are probably not prepared to accept a call except in response to a server request.

But if they were, why even keep the server in the loop as a "bridge" when the two clients can connect and talk directly?

Of course, that makes clients servers, too.

It's a thought.

[Heinz Grandjean]

Hello PB-Community,

I' ve learned that a multiple server is able to hold connection to more than one client simultaneously. So far OK; my test-sample seems to work reliable.
My question: would it be possible to have two clients (!) getting in contact with each other using this multithreaded server as (let us say) a brigde??
Or do I missunderstand TCP??

Thanks for help,
Heinz Grandjean