When using UFTP, I assign the ID from a known lookup and then reverse the lookup when processing the logs so that the logs show machine name rather than ID and I see that some ID are not in the form 0x01234567.
This causes my log to be a mixture of ID and machine name.
Is it possible that this can be improved?
How can I submit a suggestion for code changes?
Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, but in other log messages, those two distinct clients would have been expressed as 0x00001702 and 0x000009EA.
If the client identities are always expressed identically, then a mechanism that replaces 0x00001702 or 0x000009EA with the fully qualified domain name would change both correctly.
For example, the message "Received REGISTER from client ..." uses the form "0x00001702" because destinfo_t::name is set using "0x%08X" in add_dest_by_addr(), whereas the message "Transfer aborted by ..." does not use the "0x00001702" form.
Now, because I do not know the code so well, it could be that destinfo_t::name is not the same as ntohl(src) - so they should NOT be expressed the same - fair enough, but the exchange from the logging looks like they do identify the same client - in my case I don't have the unprocessed logs to log at, so I am unsure if they are the same hex value.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
When using UFTP, I assign the ID from a known lookup and then reverse the lookup when processing the logs so that the logs show machine name rather than ID and I see that some ID are not in the form 0x01234567.
This causes my log to be a mixture of ID and machine name.
Is it possible that this can be improved?
How can I submit a suggestion for code changes?
Thanks.
Which messages specifically are you referring to? Can you post some sample logs?
The messages that I see are;
"Transfer aborted by 00001702: Error joining multicast group"
"Host 000009EA not in host list"
Those messages are referring to two different clients.
Do you mean that they refer to different types of objects or diferent instance of objects ?
Certainly, I can see that they are different numbers.
Two distinct clients, each with its own ID.
Yes, but in other log messages, those two distinct clients would have been expressed as 0x00001702 and 0x000009EA.
If the client identities are always expressed identically, then a mechanism that replaces 0x00001702 or 0x000009EA with the fully qualified domain name would change both correctly.
For example, the message "Received REGISTER from client ..." uses the form "0x00001702" because destinfo_t::name is set using "0x%08X" in add_dest_by_addr(), whereas the message "Transfer aborted by ..." does not use the "0x00001702" form.
Now, because I do not know the code so well, it could be that destinfo_t::name is not the same as ntohl(src) - so they should NOT be expressed the same - fair enough, but the exchange from the logging looks like they do identify the same client - in my case I don't have the unprocessed logs to log at, so I am unsure if they are the same hex value.