Revision history [back]

Given that 100% of messages being sent over the network should be received by every other machine [..]

you are ignoring some things here, such as packet loss, processing delay in the subscribers (with resulting message loss) and other factors that will affect your dataflows. That makes this significantly more complex than you describe here.

A publishes to a topic, the message is encoded into TCP packets with the subnet broadcast address

I may be not completely up-to-date, but I don't believe TCP can be used to broadcast traffic. TCP is connection based and requires ACKs for every packet transmitted. That would get rather complex with a (potentially) unlimited nr of recipients of each message sent by the publisher.

What you're looking for I believe is multicast, and that is typically done using UDP.

One example of a transport that supports this would be ethzasl_message_transport, but I'm not sure of the state of that.

Given that 100% of messages being sent over the network should be received by every other machine [..]on the network this would double the effective available bandwidth.

you are ignoring some things here, such as packet loss, processing delay in the subscribers (with resulting message loss) and other factors that will affect your dataflows. That makes this significantly more complex than you describe here.

A publishes to a topic, the message is encoded into TCP packets with the subnet broadcast address

I may be not completely up-to-date, but I don't believe TCP can be used to broadcast traffic. TCP is connection based and requires ACKs for every packet transmitted. That would get rather complex with a (potentially) unlimited nr of recipients of each message sent by the publisher.

What you're looking for I believe is multicast, and that is typically done using UDP.

One example of a transport that supports this would be ethzasl_message_transport, but I'm not sure of the state of that.

Given that 100% of messages being sent over the network should be received by every other machine on the network this would double the effective available bandwidth.

you are ignoring some things here, such as packet loss, processing delay in the subscribers (with resulting message loss) and other factors that will affect your dataflows. That makes this significantly more complex than you describe here.

A publishes to a topic, the message is encoded into TCP packets with the subnet broadcast address

I may be not completely up-to-date, but I don't believe TCP can be used to broadcast traffic. TCP is connection based and requires ACKs for every packet transmitted. That would get rather complex with a (potentially) unlimited nr of recipients of each message sent by the publisher.publisher (also: what would something like 'window size' mean with a 1000 receivers?)

What you're looking for I believe is multicast, and that is typically done using UDP.

One example of a transport that supports this would be ethzasl_message_transport, but I'm not sure of the state of that.

Given that 100% of messages being sent over the network should be received by every other machine on the network this would double the effective available bandwidth.

you are ignoring some things here, such as packet loss, processing delay in the subscribers (with resulting message loss) and other factors that will affect your dataflows. That makes this significantly more complex than you describe here.

A publishes to a topic, the message is encoded into TCP packets with the subnet broadcast address

I may be not completely up-to-date, but I don't believe TCP can be used to broadcast traffic. TCP is connection based and requires ACKs for every packet transmitted. That would get rather complex with a (potentially) unlimited nr of recipients of each message sent by the publisher (also: what would something like 'window size' mean with a 1000 receivers?)

What you're looking for I believe is multicast, and that is typically done using UDP.

One example of a transport that supports this would be ethzasl_message_transport, but I'm not sure of the state of that.