Limitations

Top  Previous  Next
Trading and C&C > Turret Proxy To Open communication (TPO) > TPO Static Links > Static Links between TPOs not belonging to the same TSS

Static Link feature limitations

Here comes limitation directly related to the static link feature it self

Dynamic Ringdown Place only

The static link feature is limited to RingdownDynamic DDI places that only have DDI slots with attached properties. No link can be made to another place type, or to a RingdownDynamic place that has one or several slots with no property.

 

In other words, a (remote) slave Place can only points to a Remote Master Place which has attached properties to all its DDI slots.

 

No multi-layer indirection

The static link feature is limited to one level of indirection. In other words, a slave place can only points to a (remote) master. We CANNOT have a slave place pointing to another slave place.

Up to 7 slave places pointing the same master place

System is limited to 7 slave places pointing the same master place. This includes:

•Slave places created from the same TSS as the one used to create the master place

•Slave places pointing a remote master place that is a copy of the original master place

 

Consequently, this limitation is theoretical. A TSS doesn't know how many other TSS have copied its master places and how many slave places are pointing those copies. IP Trade would not provide support if this limitation isn’t respected.

Provisioning

It is not possible to create or update a Remote Cluster by provisioning.

Bulk administration

It is not possible to update a Remote Cluster or its places, lines, slots, nodes, and DNS names with bulk administration.

static link between TPOs not belonging to the same TSS limitations

Here comes limitation directly related to the static link between TPOs not belonging to the same TSS feature it self

Unicity:

There can only be one copy of the same TPO cluster per instance of TSS. A remote cluster is identified by its original identifier and the URI from which it has been copied.

Manual updates

A remote cluster is not updated when updating the original cluster. A manual operation is necessary to update the remote cluster or its places, lines, slots, nodes, and DNS names in the local TSS.

Restricted edition

A Remote Cluster and its places, lines, slots, nodes, and DNS names cannot be edited. They can simply be updated by resynchronizing the whole cluster with the remote TSS.

A slave place, once created, cannot be modified (except for few, see limitations about classic static links). E.g. it cannot be linked to another master place. IT Administrator must delete and re-create it to link it to another master place.

Synchronization

Synchronization will fail if a new cluster to copy has the same name as another cluster already saved in the local TSS.

 

When synchronizing, remote master places inside remote clusters associated to a remote TSS can either be updated or deleted:

•If a remote master place must be deleted during synchronization, it must not have any slave place pointing to it. Otherwise, the whole synchronization failed for the remote TSS.

•If a remote master place must be updated during synchronization, it must not have slave place which is started pointing to it. Otherwise, the whole synchronization failed for the remote TSS.

Copied DNS Names

DNS Names created when fetching/copying clusters cannot be linked to DDI Sharing lines.

Remote cluster URI

It’s not possible to update the URI of a remote cluster. If the URI has changed, the administrator must unlink the TSS (which will cause the deletion of all remote clusters copied with this URI) and fetch it again with the new URI.

Remote cluster deletion

It’s not possible to delete a remote cluster which contains a master place with some slave places linked to it. The administrator must first delete those salve places.

Fetching remote TPO clusters from other TSS require local TPO Clusters reset

TPO clusters which contain slave places pointing to remote TSS master places must be reset each time master clusters are fetched from remote TSS.

User Login uniqueness on TPO line

The same user (with the same User Login name) configured on two different TSS realms, can't be used at the same time on both TSSs, if both TSS realms are linked together (fetched), and both users from the two TSSs can potentially connect to the same line using TPO R-link. A User Login name connected to a TPO line needs to be unique.