RTC Forums

How does the gateway makes the connection ? Doesn't it use delayed calls internally ?
The problem is that I try to use as few resources as possible. A delayed call needs permanently a second connection as the call blocks while it waits. So reminding you about the other thread we had with those 50-100k connections, that would double the amount for sure.
The idea behind the call back server would be that the connection opens only when it is needed, which can be every 10-20 minutes for a short time and then closes again.

If you only need a connection every 10 to 20 minutes and you do not need to get the data immediately when it becomes available, why not have the Client check the Server periodically for new data (maybe once per minute)? Having a Server and a Client on both sides (which is what you seem to be doing now) is - at least in my opinion - a very bad design decision.

First of all, all your Clients need an open port for your callback implementation to work, which means that they will either be usable only from inside LAN with a static IP, or you will need to configure each Clients firewall to make it accessible from the Internet and then make sure the IP address does not change between requests. Which makes your Clients unusable from mobile devices "on the go".

And second, your Server will need a Client connection for each Client (to its "Server" port), which is going to make your Server sensitive to the way Clients operate, as well. Opening and closing connections is rather slow over TCP/IP, which means that each additional Client will be slowing your Server down quite a bit, in addition to the resource increase - used to keep opening and closing connections to different clients.

And ... third, when a Client opens and closes a connection, its Port number will remain locked for at least 2 minutes, reducing the number of available Ports for new connections. Doing this on the real Client is not a problem, since Clients usually only work with a hand full of Servers. But doing the same on a Server where you expect thousans of Clients to be connected is very likely going to become a serious problem.

Using the TRtcGateway component on the Server and a TRtcHttpGateClient on each Client, you would be having 2 open connections to the Server from each Client most of the time, but since RTC uses a thread pool and the TRtcGateway component is optimized for very high loads (tested with up to 20K Clients), you won't be having any issues with System resources when using the Gateway approach and all your Clients will be truly mobile while still being accessible and connected to each other.

Anyway ... it is your Project, so I won't try to persuade you into doing things this-or-that-way. I'm just pointing out some things I find problematic in your approach. But if you do NOT have a problem with it, then - who am I to argue? ;)

Best Regards,
Danijel Tkalcec

Thanks for the extensive answer.

The polling could be a bad design decision as well, as it happens that when an event occurs (which can happen every 10 or 20 minutes or few hours or multiple events the same time) I need to contact all clients in range immediately. Much can happen in 1 minute with polling.
I already decided at least to use the delayed callback approach and it's working for now. I can't assume to have a public mobile Ip all the time, so that way is better :) I guess, the gateway component uses a similar approach.

Atm. I use the RtcFunction to execute code on the server, using with delayed callback 2 connections. Will it work as smooth as with your gateway ? Or Do I have to expect more trouble. I'm using maybe 40 functions and it's multi threaded.

Thanks in advance,
Helge

I've already explained how the Gateway works, in THIS thread (https://rtcforum.teppi.net/index.php?topic=1204.0).
I've also explained the drawbacks of using Delayed Calls in that same thread.

Here is a copy/paste of my explanation from that thread ...
---
When you are working with the TRtcGateway component, each Client will establish two connections with the Server, one connection used exclusively for sending data from the Client to the Server and the other connection used only for sending data from the Server to one or more Clients and displatching the same packet to multiple Clients in a group, while keeping different Clients connection speeds in mind. A custom protocol was designed to allow individual packets sent from any Client to be split into smaller packet for faster sending and to reduce memory usage on the Server, so the Server will require less memory, data will be dispatched faster, negative latency effects and TCP/IP overhead will be minimized and there is no need for manual coding. It is a general-purpose Gateway component, which only handles packet dispatching.

RTC Delayed Calls, on the other hand, were introduced as a simple way to allow the Server to respond to Remote Function Calls later if data is not available immediately when a call comes in. It can be used for a lot of things where data polling is needed. Client sends a request to the Server, the Server checks if there is any data available, puts the connection to "sleep" until data is ready, "wakes" the connection up and sends a response back when there is something to send. While this also works for message dispatching (as shown in the RTC Messenger Client/Server example), every piece of data being sent from the Server to the Client requires a trip back and fort. It is not a continuous stream in one direction, as with the TRtcGateway component. This means that latency (PING times) will be playing an important role for the performance. Also, because Delayed Calls are there for use with remote functions (which are very flexible but require additional memory and a rather complex parser and serializer), there will be higher CPU and Memory requirements than using the TRtcGateway component.

In short, TRtcGateway is highly optimized and designed from ground up for message dispatching. Even dispatching larger packets (up to 16MB) between Clients would only require a few KB of RAM on the Server. Delayed Calls give you more freedom, but require more bandwidth, have negative latency effects, require more Server resources, with "user code" being an additional "risk factor" to further reduce performance and increase Server resource requirements.
---

Anyway ... I think you should decide for yourself what approach you want to go with, because (A) we are already running in circles and (B) this is a general technical support forum and not a forum for design consulting ;)

So ... if you are still undecided, then I can only advise you to read the threads again, weigh the good and the bad sides of available options (periodic polling, remote functions with delayed calls or the Gateway), then make a decision which you can stick to, without asking more questions. I can not tell you about all the possible problems you might encounter in your Project. If you want to be sure that everything will be working without any problems, then you will need to run your own tests, because the functionality of anything which is NOT strictly out-of-the-box (like the TRtcGateway component without any user code) will largely depend on your own code.

Best Regards,
Danijel Tkalcec