P2P-communications

[toniSa]

Hi,
I've the following need: when running my application on a local network (Microsoft Windows, TCP/IP) starting the application it should retain a list of all PCs running the same application. Is there a way to implemt something like this without having one computer running the serverpart where all others connect to? Ones having this internal list of PC it should be possible to send messages to single PCs (example "Hi John, there is a phonecall for you on line 4") or to all PCs (broadcast like "Hi to all, I'm going home now!"). On the other hand with such solution I could count the users running my application, very interesting for license issues.
Is there any sample application showing this behaviour? As said, I would like to avoid to have to install a separate 'server'-application.
best regards
Toni

[Kevin Powick]

You could look at UDP multicast or the approach known as Zero Configuration networking (ZeroConf).

http://en.wikipedia.org/wiki/Zeroconf

[toniSa]

Hi Kevin,
thanks for your answer. I was looking for something like the MsgConnect from Eldos but based on http-protocol and using RTC Sdk. So, almost I think, I would have to place client and server components on the same project. But is there a way to multicast (broadcast) messages or will I've to implement all the nececssary loops in code? As always, a simple sample could be very usefull to show the initial path to go.
best regards
Toni

[D.Tkalcec (RTC)]

Hi Toni,

since the HTTP protocol is working on top of the TCP/IP protocol and multicasting/broadcasting is currently only possible by using UDP, you can not use higher-level RTC SDK components to multicast. You could use low-level UDP client and server components from the RTC SDK to multicast using UDP, for which you can find one example UDP client and server implementation in the Free RTC SDK edition, but there is no official support for using these low-level RTC SDK components.

Best Regards,
Danijel Tkalcec

[D.Tkalcec (RTC)]

Anyway ...

I do not know what your project requirements are, but usually when working with the RTC SDK, you will have a single Server whose address and port are known to all Clients and all the Clients will be connecting to that single Server. If Clients need to exchange date between each other, they will do it through the Server. To make sure the Server can send data to Clients, each client would keep "polling" the Server for more data. To reduce network traffic and improve performance when using Clients which are polling the Server, RTC implements "Delayed Calls", allowing the Server to keep an active connection to the Client with the Client waiting for a response until a timeout or data is ready to be sent from the Server. One example of how this works is the RTC_Messenger demo, which allows any number of Messenger Clients to communicate with each other through a single Messenger Server.

Best Regards,
Danijel Tkalcec

[toniSa]

Hi Danijel,
I was just esaminating the RTC_Messenger demo and I think this will be the way to go. But since the "server"-part should always be accessible there will be the need to have one computer always running, the server application must be implemented as a service that starts with the system, installed on a "server"-pc (on a p2p-network it must be garanteed that this one PC is always up). To avoid all this "complications" I was looking for a way of a peer-2-peer communication between al PCs running my app on a local network, and if possible, over the http-protocol to avoid problems with blocking firewalls and there configuration. I'm not sure if I'll run in a lot of troubles making my app httpclient and httpserver the same time (one httpserver-component and n-httpclient components created runtime as there are active http-servers on the local network, or can one httpclient connect to multiple httpservers?).
best regards
Toni

[D.Tkalcec (RTC)]

1) Even though I would not recommend to make each one of your applications into a client and a server at the same time, there should be no problems using RTC HttpClient and RTC HttpServer components in the same application.

2) If your clients need to talk to more than one server at the same time, you will need a separate HttpClient component for each Server, since one HttpClient can only talk to one HttpServer at the same time. If you only want to be connected to a single HttpServer at a time, you should use a single HttpClient component and simply disconnect after switching to a new Server and reconnect again once you have set all the parameters for the new Server connection on the HttpClient component.

Best Regards,
Danijel Tkalcec

[Henrick (StreamSec)]

I was looking for a way of a peer-2-peer communication between al PCs running my app on a local network, and if possible, over the http-protocol to avoid problems with blocking firewalls and there configuration. I'm not sure if I'll run in a lot of troubles making my app httpclient and httpserver the same time

FWIW, if this is an essential requirement, I suspect you have to do it the way Danijel originally suggested, with a single server always running on some PC. While the HTTPClient should normally pass through nicely through most firewalls, the HTTPServer will likely be blocked and have to be unblocked.

[D.Tkalcec (RTC)]

As Henrick mentioned in his reply (above), only HTTP Clients are firewall-friendly and will work behind most firewalls and HTTP Proxies without having to manually configure each firewall and proxy, but ... to make your HTTP/S Server accessible to Clients over the Internet, you will need to manually configure your Servers router and firewall to accept incoming connections from the Internet.

Also, even though having Clients bundled with Server functionality so that each Client can send messages to any other Client directly may sound like a good idea now, it will not notably improve your performance inside LAN but will potentially end up in a communication mess and limit your clients accessibility over the Internet.

Having said that, I would recommend using only a single application as a HTTP/S Server, installed as a Service, while all the other applications (with a user interface) would "only" be clients and would communicate only through a Server. This would also allow you to open a port in your firewall to allow clients from all over the Internet to communicate with clients residing inside your LAN - all through that Server running as a Service inside your LAN.

Best Regards,
Danijel Tkalcec

[toniSa]

Hi Danijel, hi Henrick.
Many thanks for your explanations.
best regards
Toni