PengZheng commented on PR #690: URL: https://github.com/apache/celix/pull/690#issuecomment-1835803033
I've finished reading RFC 6762 and 6763 (word by word), and have some further remarks on `discovery_zeroconf`: ## Large TXT Records As previously pointed out by @pnoltes in a email: > One of the issue we had with mDNS, is that payload size is very limited and as result the remote service discovery was updated to a 2 step approach: The current design adopt the approach sketched by [Service Instances with Multiple TXT Records ](https://datatracker.ietf.org/doc/html/rfc6763#autoid-20). For this to work reliably, care must be taken to make sure that IP fragmentation does not happen, because > Even on hosts that normally handle Ethernet "Jumbo" packets and IP fragment reassembly, it is becoming more common for these hosts to implement power-saving modes where the main CPU goes to sleep and hands off packet reception tasks to a more limited processor in the network interface hardware, which may not support Ethernet "Jumbo" packets or IP fragment reassembly. A snapshot of mDNS wireshark capture will be very helpful to illustrate the current approach. From the current documentation (I have not checked the implementation), it is not clear how we deal with packet loss. For service whose service advertisement fit in a single message, it is never a problem. But for services generating large TXT records, how do we guarantee to collect all associated TXT records? ## Fixed Hostname and Port in SRV As mentioned above, this basically defeats the purpose of zeroconf. Don't do this! Let just use the `hostname` of the OS. For RSA over HTTP, port should be the real port listened by the HTTP server. For RSA over shared memory, port could be 0. It is OK to store URL in TXT records, but note that > The target host name and TCP (or UDP) port number of the service are given in the SRV record. This information -- target host name and port number -- MUST NOT be duplicated using key/value attributes in the TXT record. URL/URI does not necessarily contain host and port. For more, check [URI Syntax Components](https://datatracker.ietf.org/doc/html/rfc3986#autoid-17). ## Service Instance Name and Service Subtypes If the application use `rsa_shm` alone, then only service instances exported by `rsa_shm` should be discovered. This is not the case (and less than ideal) for the current implementation: all service instances are enumerated by `discovery_zeroconf`. By using service subtypes, if the application only uses `rsa_shm`, `discovery_zeroconf` should search for something like `_shm._sub._celix-rpc._udp` rather than `_celix-rpc._udp`. For a user who want to list all exported services for debugging purpose, he/she can search for `_celix-rpc._udp`. Check [ Selective Instance Enumeration ](https://datatracker.ietf.org/doc/html/rfc6763#autoid-22) for more on service subtypes. Service instance name is not used by RSA directly. It's mostly used for debugging. We only need to provide a name informative enough, mDNSResponder will help to guarantee its uniqueness: > The default name should be short and descriptive, and SHOULD NOT include the device's Media Access Control (MAC) address, serial number, or any similar incomprehensible hexadecimal string in an attempt to make the name globally unique. For discussion of why <Instance> names don't need to be (and SHOULD NOT be) made unique at the factory, see [Appendix D](https://datatracker.ietf.org/doc/html/rfc6763#appendix-D), "Choice of Factory-Default Names". For it to be information, service name alone is not enough. I suggest we include pid of the service provider, which is very important for debugging a misbehaved remote service. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@celix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
