[Transport]TCP multicast?

Mar 23, 2011 at 12:50 AM

Hi !

Are there any plans to extend the tcp transport to provide multicast?

I personally - just speculating about this option - could image, that
this is very useful. For example - sorry, just thinking - I think about
to have a state-server [I am planning a distributed system management
app] which publishes state information to several agents. This infos
must not be reliable so tcp transport looks like a good option and the
[most] agents are in the same subnet. One could see this as a
"real bus" [without the reliability].

Any ideas?

So far I know - never used multicast before - this is not much work,
and the usual networking code would remain the same, except for
the configuration and initialization.


Mar 23, 2011 at 10:32 AM

Hi mabra,

Currently we don't have plans for providing a multicast transport service. (Since TCP is by its nature unicast, you probably mean if we are planning to provide a UDP-based transport service?)

I agree with you that there are probably scenarios where this would be useful. Unfortunately, with the current AppSpace structure it would be rather complicated to integrate something like that, since the AppSpace is based on point-to-point communications (ports always have a single host).

Do you have a scenario where this would be needed? If yes, I think it still depends on the number of agents if you really need multicast - the publish/subscribe mechanism of the AppSpace should work well if the number of agents is not too large. What is the estimated number of agents / frequency of published messages in your scenario?

Best Regards

Mar 23, 2011 at 5:39 PM

Hello !

Thanks for your reply!

And sorry:I was only sloppy thinking about that. I meant IP-multicast and have never asked me,
which proto will finally be used ;-)

In my current thinking/planning situation, I am asking me, if I should use XcoAppSpace or
NServiceBus. It is the first time, that I think about a distributed app. This stems froma failed
attempt to read - for example - too many performancecounters in a short period within
a single machine. I have used IPC a bit [net remoting] and I am reading currently "everything
I need" to get more insights to the big picture.

Was just a quicky;Forget it the first time ;-)