Hi,
I don't think we knew about ns_uuid. uuid::uuid is now used in quite a few
places in the codebase.
We can do an audit and change to a wrapper proc which uses uuid::uuid or
ns_uuid depending on whether the proc is being called within NaviServer or
not... but I wanted to make sure there was a good reason to introduce the
extra complexity.
On Mon, 6 Apr 2020 at 18:26, Gustaf Neumann <neum...@wu.ac.at> wrote:
> Dear David,
>
> is there any reason not using "ns_uuid"?
>
> -g
> On 06.04.20 17:02, David Osborne wrote:
>
> Hi,
> Hope everyone is well.
>
> We encountered a situation where uuids generated by tcllib's uuid::uuid
> generate can repeat sequences under naviserver which has caused some
> issues in our codebase with collisions.
> We wondered if you would expect this behaviour?
>
> Using Debian 9.7 with Naviserver 4.99.19 tarball.
>
> We have a /usr/local/ns/tcl/test.tcl file:
>
> proc uuid_test {} {
> ns_return 200 text/plain [uuid::uuid generate]
> }
> package require uuid
> ns_register_proc GET /test.tcl uuid_test
>
> Then we start naviserver with:
> sudo /usr/local/ns/bin/nsd -u nsadmin -t /usr/local/ns/conf/nsd-config.tcl
>
> Each request starts off with unique uuids:
>
> $ curl http://127.0.0.1:8080/test.tcl
> 94648710-5503-4ecb-8853-7acd68fe289c
> $ curl http://127.0.0.1:8080/test.tcl
> de3a7eee-8b4d-45b9-b80c-71985b2b6346
> $ curl http://127.0.0.1:8080/test.tcl
> efec82f4-2e0f-43ff-a951-6abb0a9a61a9
>
> Then if we do a ns_eval -sync source of any file:
>
> $ nc 127.0.0.1 4080
> Welcome to default running at /usr/local/ns/bin/nsd (pid 12248)
> NaviServer/4.99.19 for linux built on Apr 6 2020 at 14:27:50
> Tag: tar-4.99.19
> default:nscp 1> ns_eval -sync source /usr/local/ns/tcl/file.tcl
>
> We are given the same sequence of uuids again:
>
> $ curl http://127.0.0.1:8080/test.tcl
> 94648710-5503-4ecb-8853-7acd68fe289c
> $ curl http://127.0.0.1:8080/test.tcl
> de3a7eee-8b4d-45b9-b80c-71985b2b6346
> $ curl http://127.0.0.1:8080/test.tcl
> efec82f4-2e0f-43ff-a951-6abb0a9a61a9
>
> The same issue does *not* happen with your ns_uuid implementation.
>
> We dug into the implementation details of the tcllib version. I'm not
> familiar with the uuid algorithm particularly, but it seems when initially
> called, the code generates some random data to use when making the uuid
> which it calls machinfo. This is then cached and will not change as long
> as the variable exists in memory. The only thing making each subsequent
> request different is an incrementing counter (called uid) which is used in
> the MD5 hash.
> What happens with ns_eval, is that this counter (uid) is reset, the machinfo
> stays the same, so the same sequence of uuids begins again.
>
> https://github.com/tcltk/tcllib/blob/master/modules/uuid/uuid.tcl#L37
>
> What's your take on this behaviour?
> Thanks,
> --
> David
>
>
> _______________________________________________
> naviserver-devel mailing
> listnaviserver-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
> _______________________________________________
> naviserver-devel mailing list
> naviserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>
--
*David Osborne | Software Engineer*
Qcode Software, Castle House, Fairways Business Park, Inverness, IV2 6AA
*Email:* da...@qcode.co.uk | *Phone:* 01463 896 484
www.qcode.co.uk
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
