As a minimum at least the specification should describe this topic - it could also be discussed in part 14 also - it might also require some more specific behavior for device models. Also the configuration tools might need to discuss this.

I think Part 14 already states the IANA registered port 4840 and that this is the default port.
It is not possible to restrict the communicaton to this port since it would not work if there is more than one application on a device/PC.

But I agree that it would be good to have a capability that indicates the valid ports. The actually used port is visible as soon as a PubSubConnection is configured and it would be possible to configure "empty" PubSubConnections but this would be overhead to just indicate what are valid ports.

If the valid ports are in the capabilities, this information should then also be available in the offline descriptor.

Part 14 says 4840 is the "default and recommended port", and that "other ports may be used", but it doesn't deal with the problem of how does a tool configuring PubSub know what "other ports" can be used on a subscriber. Agree that if there are multiple, independent applications then mandating 4840 would be problematic. For the normal case for controller & devices, it's likely not an issue, but would be good to be able to handle the multiple application case. There are probably multiple ways to solve it (adding the port number somewhere in the UAFX info model, or as with the CommunicationIds, add a sub-command to the EstablishConnections to get the port number(s)). Putting it in the descriptor is problematic, because if the device is using ephemeral ports (which it should in this case, since in general you should not use a port registered for something else) then you may not know the port number until run time).

The ReserverIds is already doing this for PublisherId, WriterGroupId and DataSetWriterId to be able to get all addressing related information before the PubSub configuration is actually created.

We can potentially extend the ReserveIds option to return additional information needed for PubSubConnection level. We return already the default PublisherId but this is returned in a BaseDataType and we pass in the TransportProfileUri. So we would be able to return a structure with more information than just the PublisherId.

To add a sub command would be easier than to added additional fields in the result arguments/structures. The ReserveIds would be an option if the "additional Transport Information" is requested. In this case we can make sure the caller understands the additional structure returned instead of the pure PublisherId.

Another option would be a capability variable similar to the DefaultPublisherId that we have already AND return in ReserveIds.

There are 2 options to pass the port number in return of ReserveIds command:

• subtype PubSubReserveCommunicationIdsResultDataType
• or overload the PublisherId field.

There are also 2 options to request the "additional transport information":

• Introduce another command bit for EstablishConnections
• or subtype PubSubReserveCommunicationIdsDataType

I reviewed the above possibilities, and to me the most clean solution would be to add subtypes. I wrote my proposal in the Part 81 draft. If you don't like it this way, we can revert it and explore another possibilities.

image.png (63,641 bytes)   

image.png (63,641 bytes)   

image-2.png (17,512 bytes)   

image-2.png (17,512 bytes)   

image-3.png (32,526 bytes)   

image-3.png (32,526 bytes)