Wish for subnet virtual virtual appliance

[tmart]

It would be very useful to allow more than point-to-point communications without resorting to the external Ethernet interface.

What I have in mind would be a virtual catalog object that when dragged onto the canvas would allow the provisioning of a subnet (the size of which could be a property of the object) to which multiple other objects could connect. The subnet object object would have only input terminals (ie. no output terminals). This object would leverage the functionality of AppLogic 2.3 beta that allows for 2-way connections.

Any appliance connected to that subnet object could communicate with anything else connected to that subnet.

Specifically, this subnet object should not create another running object that would yield more moving parts or an additional point of failure. It is tempting to implement this as a stripped-down Linux appliance that simple functions as a packet router/network hub; however, there is no need to add such an appliance if the network endpoints could "simply" allow a subnet instead of a point-to-point connection.

Please note that 2-way connections a la AppLogic 2.3beta do not remove the need/desire for this request.

Thanks.

[PeterNic]

tmart,

I understand the use case and agree. The enabling of reverse traffic initiation for 'any' protocol addresses a different issue, does not cover this use case.

This, for example, will help support JBOSS clustering and other similar clustering methods. One thing to we will need to consider internally is that broadcast/groupcast traffic would be nice to support; and at the same time, we don't want it to propagate all over the backbone and create load for all servers.

We will add this to the list of features requests to review this with the engineering team; thanks for the input.

BTW, is broadcast/groupcast needed in your use case?

Regards,
-- Peter

[tmart]

I am not sure if broadcast/groupcast will completely solve the general issue, but it might. Maybe I'm not totally clear on what you are suggesting. It seems like this might limit the applicability though.

If there is a possibility of, as I suggested above, creating an object on the canvas which causes a subnet to be created along with an appropriately configured virtual interface for each of the terminals that are wired to it... allowing either auto subnet sizing (based upon number of things connected *to* it) or the specification of the subnet size via a property, that'd be perfect.

It seems (from my perspective) like a nice fit for your GUI model... because one would want to see the components that participate in that subnet (as well as the ports on which they communicate). The trick, it seems, would be to provide names that resolved to IP addresses in a predictable manner so that the peers could communicate without broadcast or brute-force RARP discovery.

Maybe you could use something like the annotation feature of the new AppLogic in order to require/allow the arcs to have labels that would become the hostnames that resolved to the appropriate IP addresses. For example, if we had three nodes connected to the subnet object via their "out" terminals, we could label the arcs (the wires) as "L1" "L2" and "L3" and each of the peers in the subnet would thus be able to reference each other (and even themselves) via those labels. Just an idea. You probably have better ideas, but I think that it is imperative that this functionality provide a predictable means to refer to the members of the subnet without having to know runtime IP addresses.

[PeterNic]

tmart,

I meant whether, if something like that should exist, you'd need groupcast/broadcasts to work over this "virtual subnet" (not as an alternative but as a feature of it).

The note about the name resolution was important, too, so it is good that it came out.

Regards,
-- Peter