# Node capabilities and subject-id assignment **URL:** \ **Category:** CLI tools (Cynic/Yakut)\ **Created:** [July 8, 2022, 12:01am UTC](https://forum.opencyphal.org/t/node-capabilities-and-subject-id-assignment/1704 "2022-07-08T00:01:56Z")\ **Posts on this page:** 1\ **Showing post:** 9
**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\ **Post date:** [July 18, 2022, 7:43am UTC](https://forum.opencyphal.org/t/node-capabilities-and-subject-id-assignment/1704/9 "2022-07-18T07:43:19Z")
> [@pat1](#): > > Is not clear to me which user defined service need/can have constant port-ID. _ **None.** _ None of the user-defined data types can have a fixed port-ID (with a marginal exception, which is not worth mentioning here probably). This is explained in the Specification (chapter 2 “Basic concepts”) and the Guide. This is not DroneCAN. Forget custom fixed port-ID, it was a terrible idea, and there is a good reason why they are no longer available in Cyphal. There are countless discussions on this forum about this already; here’s one: [Choosing Message and Service IDs](https://forum.opencyphal.org/t/choosing-message-and-service-ids/889). > [@pat1](#): > > Calling a service need to specify a node-id Correct. > [@pat1](#): > > so is correct in general to define a fixed port-ID for services in DSDL ? No, and for the same reason why it is not correct to use fixed port-IDs with custom message types. A node may provide multiple instances of the same service, and it is not appropriate for the data type designer to prohibit that (unless we are talking about the very basic low-level services provided by the protocol itself, but we are not talking about them right now). Generally, one should not expect to see many custom service types since they are somewhat limited in their ability to express complex abstractions. Let me quote the Guide: > [@The Cyphal Guide](https://forum.opencyphal.org/t/the-cyphal-guide/778/5): > > Observe that relying on node-IDs to differentiate the service instances or agents would be a mistake for two reasons. The first reason is that a node-ID, per the Cyphal network model, is a transport-layer property that exists primarily to facilitate the operation of the network itself rather than to enrich the application-level contracts. Relying on the node-ID to define application-level functions constitutes a leaky abstraction throughout the layers separating the application and the transport. The second reason is that such separation presumes that each service instance or agent should be implemented by a separate node, which is not an adequate assumption for a service designer to make. > > An attentive reader here might notice that Cyphal-services (not “architectural services” but “services as opposed to subjects”) are inherently bound to node-IDs and as such their ability to participate in well-architected network services is limited. This is a correct observation. This design is one manifestation of Cyphal’s commitment to providing powerful abstractions at zero cost – occasionally, certain trade-offs have to be made. Many practical services will be designed based on subjects alone without relying on Cyphal-services at all. --- _[View the full topic](https://forum.opencyphal.org/t/node-capabilities-and-subject-id-assignment/1704)._