TCP Multicast and Multithreading

Question

I need to come up with clients who can repeatedly transfer data to other clients. This means that I will use TCP for a reliable connection between clients in the multicast group. Is this not suitable for n ^ 2 connections? It seems a little silly to me. Wouldn’t there be / shouldn’t be a way of easier multicast with reliability?

EDIT: UNIX / C

EDIT: I did not specify how multithreading comes into play. but if I were to open n ^ 2 connections, I thought that I would be multithreaded and that there would be even more complications than I would like.

Answer 1

There are several reliable multicast solutions.

• DDS (Data Distribution Service)
• Standard protocol
• PGM

I tried the first two.

Norma is simple, works like a standard multicast udp, but includes nacks ... excelent if you don't need more. There are some implementations that also support bandwidth adaptation and other improvements.

DDS is a step forward. This is really great (I know the RTI implementation and works great) and has many features as well as a very good design. It is based on reliability and fault tolerance and there is an open implementation .

By the way, at least DDS and NORM do not require n ^ 2 connections. They work as multicast udp.

Answer 2

Depending on your target platform ....

You can take a look at Pragmatic General Multicast . This, as I understand it, uses Microsoft MSMQ and Tibco Rendezvous, and it can be accessed through Winsock (see: http://msdn.microsoft.com/en-us/library/ms740125(VS.85).aspx ) .

Answer 3

You need to take a look at 0MQ , which is a high-speed messaging system that has one of the features of reliable multicast using Pragmatic General Multicast (PGM) using OpenPGM .

Recently there was an article on lwn.net:

0MQ: A New Messaging Approach

Answer 4

multicast and TCP are mutually exclusive.

Implementing reliable UDP delivery is nuts. No one has been doing this since the 1980s, and it's impossible to do as well as any cheap TCP stack, in terms of performance and BW overhead. Correction: sometimes this is done manually, but only by exotic vehicles, such as very long or narrow pipes.

N ^ 2 connections are not very stupid. Connection with 1 Hz keepalives is not expensive. What are the costs of traffic. This is what you need to concentrate on.

Answer 5

Of course, there is a more efficient way - you stay using UDB and overload reliable sending. However, no. But at least you only need to send the sent ONCE packets to the sending site.

Answer 6

PGM is an option, as mentioned above. The problem we are faced with is that if the client cannot keep up with reading the incoming data, it is disconnected.

Since we could never reliably guarantee "reasonably fast" clients, we implemented our own reliability protocol on top of UDP multicast. The implementation is not completely general when it comes to dynamic connections / disconnections, but this may work for you. You can find the implementation here:

http://www.equalizergraphics.com/cgi-bin/viewvc.cgi/trunk/src/lib/net/rspConnection.h?view=markup http://www.equalizergraphics.com/cgi-bin/viewvc.cgi /trunk/src/lib/net/rspConnection.cpp?view=markup

Answer 7

Just a thought, but your work must be done using a network protocol. You can also take a look at implementing this using a messaging service with a publication-based model.

If you need network connectivity, you will have to deal with a variety of connections or with delivery on your own. Before you go down this road, make sure of your requirements.