|
General Q/A
< Previous Next >
re: Suggestion: mountains of IDs
Kevin Houstoun / Citigroup
8 May 2004 6:31AM ET > Hi,
> I agree with the latter proposal but with some apprehension.
>
> I think having ids in a repeating group is not a wise idea. Firstly these ids are company or implementation specific which are shielded from the connecting counter party. It would not make any sense to expose them in the message.
> Secondly. this will consume extra space in the message, not to mention processing/logging overheads and I dont think that the cost-benefit ratio warrants a change towards it.
>
> I do like the idea about the Globally Unique Identifiers as order ids. But in order to accomplish this, every engine would have to ensure that it is generating that identifier properly. The only problem is the executing party will have no easy way of determining the fact that this identifier is in fact globally unique. Relying on other ppl not to committ mistakes is in itself a mistake.
>
> Kashif Awan,
> kashif.awan@kolachi.net.
> Manager Electronic Connectivity,
> Kolachi Advanced Technologies.
> www.kolachi.com.
>
>
> > I'd like to add a couple of points to the ideas raised. First, I agree that walking a tree (find order A, then find the order id that it replaces, then find that replaced order, find the order id it replaces...and so on) to find the complete history of an order is an unwelcome chore when supporting FIX.
> >
> > By adding a repeating group of every order id this would be helpful in that you can immediately get to the nth order by looking for the nth member of the repeating group.
> >
> > I'd modify this proposal slightly by adding in a new datatype of uniqueidentifier which would then be used in as for the order id. The benefit of this is that by having genuinely unique order ids across sessions, clients, engines, days (whatever) the process of searching databases and log files for order ids would be much simpler. The order id would then be generated using a standard tool (such as CoCreateGuid in the windows OLE32.DLL).
> >
> >
> > This would make order ids not human readable (such as 32EEAEE2F42248de85E71185926C9E0B) but genuinely unique, without requiring any centralisation of order id assignment.
> >
> > For more about how/what a guid is have a look at www.dsps.net/uuid.html or http://hegel.ittc.ukans.edu/topics/internet/internet-drafts/draft-l/draft-leach-uuids-guids-01.txt
> >
> >
> >
>
GUID's have been discussed in the past. c 2001 In particular they where discuss in the space of intelligent trade matching, (if both side of the trade shared a GUID the matching would not need to be that intelligent).
They where presented at conferences around the same time as the GSTPA, OMGEO debate was going on.
The major hurdle seemed to be the industry view that you could achieve the same using a combination (concatenation) of the existing fields and that GUID's are basically too long for many existing systems to handle as identifiers. I know of systems with 8, 12 and 20 digit restrictions on the length of ID's.
I still believe that a genuinely globally unique identifier make a lot of sense.
Cheers
Kevin Houstoun
Citigroup
re: Suggestion: mountains of IDs
Kevin Houstoun / Citigroup 8 May 2004 6:31AM ET
|
