Send and receive data in real time

The OS is the first possible problem here... not all of them are deterministic... imagine Windows... if you need to process something in real time and the OS starts defragmenting or you launch another application that could need a lot of resources that could reduce the resource pool available for your application...

i.e. Imagine an app to control an inverse pendulum using a computer... and that you suddenly put a floppy disk in the A: unit and start writing information into it... probably the pendulum will fall...

Depending on the real needs of your "real time" you will be fine... if not... you can be in a really big problem...

You will have to determine the way you need to process the data:

- getting all the information always.
- allowing the program to reject some packets as they are out of the good time to be received...
...

Give us more details and we will extend our answer...

Anyway... good luck with that "beginner" project...

In addition to the answer by Manfred: this is some basic explanation of real time.

Hard real time system is the system where the maximum latency of some time-critical response can be found in advance, and the system must guarantee 100% probability of completion of the response in this time frame. This is pretty hard to achieve in principle. This is not about certain time itself, this is about the guarantee of response in time.

In one typical scenario, some part of throughput is sacrificed to the guarantee. The whole idea of hard real time is always related to the control of some hardware and processing driven by a hardware interrupt.

If you think about Windows in general you will understand that the hard real-time properties have nothing to do with Windows. Even if you apply real-time priority for a Windows thread/process, it won't guarantee certain predictable latency as this latency will depend on current operational status of the system (more or less busy with other priority threads, status of the cache of all levels (important limiting factor!) and stuff like that. If Ethernet is involved (set aside absolutely non-deterministic Internet), it's always introduces some probability of unlimited delays, as Ethernet architecture of resolution of clashes is totally based on a non-deterministic algorithm. Theoretically speaking, its possible to guarantee some slower hard real-time networking for a network with fixed number of players by scheduling and throttling all players in order to avoid conflicts; it should be based on some single central arbitrator device.

Everything outside the realm of hard real time is called soft real-time or something like that. I'm not sure if there is a commonly accepted and valid classification of not hard real time systems.
See http://en.wikipedia.org/wiki/Real-time_computing[^] and http://en.wikipedia.org/wiki/Real-time_operating_system[^].

Sometimes people call real-time something very specific. For example, there is a common term "real-time" applied to some important sub-system, such as related to multimedia. Needless to say that a media player, for example, should guarantee the fixed audio tempo and/or fixed frame rate. In this sense, it is really a hard real-time subsystem but— until the user does something active and CPU time consuming in parallel. In real life that video may start stalling. This is kind a real time but not of the true kind. True hard real time is used it military, transport systems and the like.

—SA

Take a look at ACE[^], The ADAPTIVE Communication Environment and TAO[^], Real-time CORBA with TAO.

As you can see here: ACE, TAO, and CIAO Success Stories[^] - this is used by some serious players in the field of real-time development.

Here is a short tutorial: ACE programmers Guide[^]

Here are some books on ACE:
http://www.riverace.com/acebooks/index.htm[^]

Best regards
Espen Harlinn

One more thing to investigate: the requirement of "search all available servers", unless you are in a very small and controlled environment, is a nonsense in today's Internet mainly for two reasons:
- There is no concept of "World-Wide broadcast". Fortunately! (imagine what the activity of every network interface allover the world would be if such a mechanism existed and went abused!)
- That said, you can heuristically scan all the available addresses and ports to try to get meaningful answers from them. It can take days, and your behavior can be considered "viral" and your address blocked as "malicious".

A more proper way to solve this problem is
- Define a "well known place(s)" (whose address(es) is (are) supposed to be already known, or easily queried by a DNS) where all of your server register their availability and status, and all of your client can ask for the "best available server" or for the "list of registered servers".
- Define an authentication mechanism to allow only authorized server to be really able to join this "registration service" and only authorized clients to access the given information. The security of such a mechanism (just a plain ID/password, individual password, challenge-token based, etc.) depends on the protection level you need.
Note that such a task is -before than an algorithm- the definition of a "protocol".

Note that the Dynamic-DNS protocol itself allows to solve the problem, if you register a "service locator record" and bind to that "service" all of your servers. If you refer to such method you have the advantage to have a "standard Internet application" that can be used mostly everywhere.

Once a client has located an appropriate server, normal socket programming is needed to transfer data. But -again- consider the advantage to use a standard protocol like (for example) HTTP: in its basic functionality is relatively simple to be implemented (you don't need to parse whatever HTML, if not required). That will give to your application the necessary openness to evolve even in a variety of different form and formats.