Thread: [Quickfix-developers] ClOrdID protocol??
Brought to you by:
orenmnero
Menu
▾
▴
quickfix-developers
|
From: Andrew M. <an...@nm...> - 2003-07-23 22:57:16
|
If a client program uses a simple counter to generate Order IDs and the client exits and then restarts, the ClOrdID is reset to 1. Orders sent after that get a "duplicate ClOrdID" reject until more orders are sent than were sent by the previous session (when new ClOrdIDs start being generated). What is the standard procedure, if any, to ensure uniqueness of ClOrdIDs between disconnects, crashes, etc? Should an OMS query the message store on startup for the highest ClOrdID used that day and begin incrementing it? Should it assure uniqueness by appending a session counter to the end of the ID? Should it simply tack on time&date? Thanks Andrew Munn and...@ho... |
|
From: Oren M. <ore...@ya...> - 2003-07-24 15:32:21
|
There is no standard protocol for this. In fact, some exchanges won't even look at it, they often treat it as a pass thru value. Generally, you just need to insure somehow that it is unique for the extent of the session. Whatever way you choose to do that is entirely up to you. One thing you should verify is the maximum length your counterparty supports. Although there is no restriction on the length of a FIX field, the counterparty usually stores this value in a database which forces a length restriction on their end. If their length restriction is hig enough, you can use a UUID. Otherwise time + counter could be sufficient. Or simply persisting somewhere the last id that you used. --- Andrew Munn <an...@nm...> wrote: > If a client program uses a simple counter to > generate Order IDs and the > client exits and then restarts, the ClOrdID is reset > to 1. Orders sent > after that get a "duplicate ClOrdID" reject until > more orders are sent > than were sent by the previous session (when new > ClOrdIDs start being > generated). > > What is the standard procedure, if any, to ensure > uniqueness of ClOrdIDs > between disconnects, crashes, etc? Should an OMS > query the message > store on startup for the highest ClOrdID used that > day and begin > incrementing it? Should it assure uniqueness by > appending a session > counter to the end of the ID? Should it simply tack > on time&date? > > > Thanks > Andrew Munn > and...@ho... > > > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built > ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are > available now. > Download today and enter to win an XBOX or Visual > Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Patrick R. <pat...@ya...> - 2003-07-24 15:57:11
|
One thing though - try no to link reset of sequence number with reset of clordid if you use such thing. Furthermore, most people reset their session every 24 hours. If you trade in different regions, you always have orders in one place, so doing a reset of clordid every day is not great either (actually, it just will not work). the best is to try to never use the same orderid or eventually recycle every month I guess (watch out for GTC/GTD orders though) Concerning length, in my case, we're limited to 12 chars by the servers that are connected to the exchange, on top of that, these same servers hate when the format of this clientordid changes. --- Oren Miller <ore...@ya...> wrote: > There is no standard protocol for this. In fact, > some > exchanges won't even look at it, they often treat it > as a pass thru value. Generally, you just need to > insure somehow that it is unique for the extent of > the > session. Whatever way you choose to do that is > entirely up to you. > > One thing you should verify is the maximum length > your > counterparty supports. Although there is no > restriction on the length of a FIX field, the > counterparty usually stores this value in a database > which forces a length restriction on their end. If > their length restriction is hig enough, you can use > a > UUID. Otherwise time + counter could be sufficient. > > Or simply persisting somewhere the last id that you > used. > > --- Andrew Munn <an...@nm...> wrote: > > If a client program uses a simple counter to > > generate Order IDs and the > > client exits and then restarts, the ClOrdID is > reset > > to 1. Orders sent > > after that get a "duplicate ClOrdID" reject until > > more orders are sent > > than were sent by the previous session (when new > > ClOrdIDs start being > > generated). > > > > What is the standard procedure, if any, to ensure > > uniqueness of ClOrdIDs > > between disconnects, crashes, etc? Should an OMS > > query the message > > store on startup for the highest ClOrdID used that > > day and begin > > incrementing it? Should it assure uniqueness by > > appending a session > > counter to the end of the ID? Should it simply > tack > > on time&date? > > > > > > Thanks > > Andrew Munn > > and...@ho... > > > > > > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by: Free pre-built > > ASP.NET sites including > > Data Reports, E-commerce, Portals, and Forums are > > available now. > > Download today and enter to win an XBOX or Visual > > Studio .NET. > > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > > _______________________________________________ > > Quickfix-developers mailing list > > Qui...@li... > > > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site > design software > http://sitebuilder.yahoo.com > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built > ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are > available now. > Download today and enter to win an XBOX or Visual > Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Patrick R. <pat...@ya...> - 2003-07-24 16:05:10
|
We have some bad networking issues with a Client using QuickFix (1.5) Have a look at the log below (sorry for the size..) we are in a bad loop. Let me know if you can make sense of it. It happened many times the same day, always the same problem of FIX engine asking resend to each other, even if it does get more complicated as the day went by... below is just the beginning of the problem. The thing I dont like though, is that our server sends the resend request first (!) and the client answers/ask a resend with a sequence number that is not the one we requested in the resend request - so we're stuck. FINE Sending : 8=FIX.4.2|9=59|35=0|49=CLIENTTARGET|56=CLIENTSEND|34=337|52=20030724-06:35:05|10=196| Receiving : 8=FIX.4.2|9=59|35=0|34=339|49=CLIENTSEND|52=20030724-06:35:28|56=CLIENTTARGET|10=203| Sending : 8=FIX.4.2|9=59|35=0|49=CLIENTTARGET|56=CLIENTSEND|34=338|52=20030724-06:35:35|10=200| Sending : 8=FIX.4.2|9=82|35=1|49=CLIENTTARGET|56=CLIENTSEND|34=339|52=20030724-06:36:00|112=HeartBtExt Timeout|10=115| Receiving : 8=FIX.4.2|9=111|35=3|34=340|49=CLIENTSEND|52=20030724-06:31:15|56=CLIENTTARGET|45=339|58=SendingTime accuracy problem|372=1|373=10|10=238|^M Login OUT ok Receiving : 8=FIX.4.2|9=59|35=5|34=341|49=CLIENTSEND|52=20030724-06:31:15|56=CLIENTTARGET|10=193|^M Sending : 8=FIX.4.2|9=81|35=5|49=CLIENTTARGET|56=CLIENTSEND|34=340|52=20030724-06:36:00|58=Replying to logout|10=108|^M Login IN OK Receiving : 8=FIX.4.2|9=71|35=A|34=342|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|98=0|108=30|10=224| Sending : 8=FIX.4.2|9=71|35=A|49=CLIENTTARGET|56=CLIENTSEND|34=341|52=20030724-06:36:35|98=0|108=30|10=231| Server Receives 344 (where is 343?) Receiving : 8=FIX.4.2|9=59|35=5|34=344|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=195| Server Resend request for 343 Sending : 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=342|52=20030724-06:36:35|7=343|16=0|10=163| Client Resend request for 340 (that was the logout answer above) ?? + asks that with 345, not 343 we requested -> we loop and hit a dead end... Receiving : 8=FIX.4.2|9=72|35=2|34=345|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|7=340|16=340|10=004| Sending : 8=FIX.4.2|9=77|35=4|49=CLIENTTARGET|56=CLIENTSEND|34=340|52=20030724-06:36:35|43=Y|123=Y|36=341|10=048| Sending : 8=FIX.4.2|9=77|35=1|49=CLIENTTARGET|56=CLIENTSEND|34=343|52=20030724-06:36:35|112=synchronized?|10=247| Sending : 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=344|52=20030724-06:36:35|7=343|16=0|10=165| Receiving : 8=FIX.4.2|9=111|35=3|34=346|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=342|58=SendingTime accuracy problem|372=2|373=10|10=238| Sending : 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=345|52=20030724-06:36:35|7=343|16=0|10=166| Receiving : 8=FIX.4.2|9=59|35=5|34=347|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=198| Sending : 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=346|52=20030724-06:36:35|7=343|16=0|10=167| Receiving : 8=FIX.4.2|9=111|35=3|34=348|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=340|58=SendingTime accuracy problem|372=4|373=10|10=240| Sending : 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=347|52=20030724-06:36:35|7=343|16=0|10=168| Receiving : 8=FIX.4.2|9=59|35=5|34=349|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=200| Sending : 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=348|52=20030724-06:36:35|7=343|16=0|10=169| Receiving : 8=FIX.4.2|9=111|35=3|34=350|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=343|58=SendingTime accuracy problem|372=1|373=10|10=233| Sending : 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=349|52=20030724-06:36:35|7=343|16=0|10=170| __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Oren M. <ore...@ya...> - 2003-07-24 16:36:47
|
What's with all the SendingTime Accuracy problems? --- Patrick Reuter <pat...@ya...> wrote: > We have some bad networking issues with a Client > using > QuickFix (1.5) > > Have a look at the log below (sorry for the size..) > we are in a bad loop. > Let me know if you can make sense of it. > > It happened many times the same day, always the same > problem of FIX engine asking resend to each other, > even if it does get more complicated as the day went > by... below is just the beginning of the problem. > The > thing I dont like though, is that our server sends > the > resend request first (!) and the client answers/ask > a > resend with a sequence number that is not the one we > requested in the resend request - so we're stuck. > > > > > > FINE > Sending : > 8=FIX.4.2|9=59|35=0|49=CLIENTTARGET|56=CLIENTSEND|34=337|52=20030724-06:35:05|10=196| > Receiving : > 8=FIX.4.2|9=59|35=0|34=339|49=CLIENTSEND|52=20030724-06:35:28|56=CLIENTTARGET|10=203| > Sending : > 8=FIX.4.2|9=59|35=0|49=CLIENTTARGET|56=CLIENTSEND|34=338|52=20030724-06:35:35|10=200| > Sending : > 8=FIX.4.2|9=82|35=1|49=CLIENTTARGET|56=CLIENTSEND|34=339|52=20030724-06:36:00|112=HeartBtExt > Timeout|10=115| > Receiving : > 8=FIX.4.2|9=111|35=3|34=340|49=CLIENTSEND|52=20030724-06:31:15|56=CLIENTTARGET|45=339|58=SendingTime > accuracy problem|372=1|373=10|10=238|^M > > Login OUT ok > Receiving : > 8=FIX.4.2|9=59|35=5|34=341|49=CLIENTSEND|52=20030724-06:31:15|56=CLIENTTARGET|10=193|^M > Sending : > 8=FIX.4.2|9=81|35=5|49=CLIENTTARGET|56=CLIENTSEND|34=340|52=20030724-06:36:00|58=Replying > to logout|10=108|^M > > Login IN OK > Receiving : > 8=FIX.4.2|9=71|35=A|34=342|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|98=0|108=30|10=224| > Sending : > 8=FIX.4.2|9=71|35=A|49=CLIENTTARGET|56=CLIENTSEND|34=341|52=20030724-06:36:35|98=0|108=30|10=231| > > Server Receives 344 (where is 343?) > Receiving : > 8=FIX.4.2|9=59|35=5|34=344|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=195| > Server Resend request for 343 > Sending : > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=342|52=20030724-06:36:35|7=343|16=0|10=163| > Client Resend request for 340 (that was the logout > answer above) ?? + asks that with 345, not 343 we > requested > -> we loop and hit a dead end... > Receiving : > 8=FIX.4.2|9=72|35=2|34=345|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|7=340|16=340|10=004| > Sending : > 8=FIX.4.2|9=77|35=4|49=CLIENTTARGET|56=CLIENTSEND|34=340|52=20030724-06:36:35|43=Y|123=Y|36=341|10=048| > Sending : > 8=FIX.4.2|9=77|35=1|49=CLIENTTARGET|56=CLIENTSEND|34=343|52=20030724-06:36:35|112=synchronized?|10=247| > Sending : > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=344|52=20030724-06:36:35|7=343|16=0|10=165| > Receiving : > 8=FIX.4.2|9=111|35=3|34=346|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=342|58=SendingTime > accuracy problem|372=2|373=10|10=238| > Sending : > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=345|52=20030724-06:36:35|7=343|16=0|10=166| > Receiving : > 8=FIX.4.2|9=59|35=5|34=347|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=198| > Sending : > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=346|52=20030724-06:36:35|7=343|16=0|10=167| > Receiving : > 8=FIX.4.2|9=111|35=3|34=348|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=340|58=SendingTime > accuracy problem|372=4|373=10|10=240| > Sending : > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=347|52=20030724-06:36:35|7=343|16=0|10=168| > Receiving : > 8=FIX.4.2|9=59|35=5|34=349|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=200| > Sending : > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=348|52=20030724-06:36:35|7=343|16=0|10=169| > Receiving : > 8=FIX.4.2|9=111|35=3|34=350|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=343|58=SendingTime > accuracy problem|372=1|373=10|10=233| > Sending : > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=349|52=20030724-06:36:35|7=343|16=0|10=170| > > > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site > design software > http://sitebuilder.yahoo.com > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built > ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are > available now. > Download today and enter to win an XBOX or Visual > Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Patrick R. <pat...@ya...> - 2003-07-24 16:44:44
|
Dont know, havent looked at it. QuickFix apparently is sending that to us(guess not), or maybe the client's app ?... I agree though : strange reject messages. I am trying to figure out the resend issue first, I'll see about the app complaining later on (not too late !) --- Oren Miller <ore...@ya...> wrote: > What's with all the SendingTime Accuracy problems? > > --- Patrick Reuter <pat...@ya...> wrote: > > We have some bad networking issues with a Client > > using > > QuickFix (1.5) > > > > Have a look at the log below (sorry for the > size..) > > we are in a bad loop. > > Let me know if you can make sense of it. > > > > It happened many times the same day, always the > same > > problem of FIX engine asking resend to each other, > > even if it does get more complicated as the day > went > > by... below is just the beginning of the problem. > > The > > thing I dont like though, is that our server sends > > the > > resend request first (!) and the client > answers/ask > > a > > resend with a sequence number that is not the one > we > > requested in the resend request - so we're stuck. > > > > > > > > > > > > FINE > > Sending : > > > 8=FIX.4.2|9=59|35=0|49=CLIENTTARGET|56=CLIENTSEND|34=337|52=20030724-06:35:05|10=196| > > Receiving : > > > 8=FIX.4.2|9=59|35=0|34=339|49=CLIENTSEND|52=20030724-06:35:28|56=CLIENTTARGET|10=203| > > Sending : > > > 8=FIX.4.2|9=59|35=0|49=CLIENTTARGET|56=CLIENTSEND|34=338|52=20030724-06:35:35|10=200| > > Sending : > > > 8=FIX.4.2|9=82|35=1|49=CLIENTTARGET|56=CLIENTSEND|34=339|52=20030724-06:36:00|112=HeartBtExt > > Timeout|10=115| > > Receiving : > > > 8=FIX.4.2|9=111|35=3|34=340|49=CLIENTSEND|52=20030724-06:31:15|56=CLIENTTARGET|45=339|58=SendingTime > > accuracy problem|372=1|373=10|10=238|^M > > > > Login OUT ok > > Receiving : > > > 8=FIX.4.2|9=59|35=5|34=341|49=CLIENTSEND|52=20030724-06:31:15|56=CLIENTTARGET|10=193|^M > > Sending : > > > 8=FIX.4.2|9=81|35=5|49=CLIENTTARGET|56=CLIENTSEND|34=340|52=20030724-06:36:00|58=Replying > > to logout|10=108|^M > > > > Login IN OK > > Receiving : > > > 8=FIX.4.2|9=71|35=A|34=342|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|98=0|108=30|10=224| > > Sending : > > > 8=FIX.4.2|9=71|35=A|49=CLIENTTARGET|56=CLIENTSEND|34=341|52=20030724-06:36:35|98=0|108=30|10=231| > > > > Server Receives 344 (where is 343?) > > Receiving : > > > 8=FIX.4.2|9=59|35=5|34=344|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=195| > > Server Resend request for 343 > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=342|52=20030724-06:36:35|7=343|16=0|10=163| > > Client Resend request for 340 (that was the logout > > answer above) ?? + asks that with 345, not 343 we > > requested > > -> we loop and hit a dead end... > > Receiving : > > > 8=FIX.4.2|9=72|35=2|34=345|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|7=340|16=340|10=004| > > Sending : > > > 8=FIX.4.2|9=77|35=4|49=CLIENTTARGET|56=CLIENTSEND|34=340|52=20030724-06:36:35|43=Y|123=Y|36=341|10=048| > > Sending : > > > 8=FIX.4.2|9=77|35=1|49=CLIENTTARGET|56=CLIENTSEND|34=343|52=20030724-06:36:35|112=synchronized?|10=247| > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=344|52=20030724-06:36:35|7=343|16=0|10=165| > > Receiving : > > > 8=FIX.4.2|9=111|35=3|34=346|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=342|58=SendingTime > > accuracy problem|372=2|373=10|10=238| > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=345|52=20030724-06:36:35|7=343|16=0|10=166| > > Receiving : > > > 8=FIX.4.2|9=59|35=5|34=347|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=198| > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=346|52=20030724-06:36:35|7=343|16=0|10=167| > > Receiving : > > > 8=FIX.4.2|9=111|35=3|34=348|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=340|58=SendingTime > > accuracy problem|372=4|373=10|10=240| > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=347|52=20030724-06:36:35|7=343|16=0|10=168| > > Receiving : > > > 8=FIX.4.2|9=59|35=5|34=349|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=200| > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=348|52=20030724-06:36:35|7=343|16=0|10=169| > > Receiving : > > > 8=FIX.4.2|9=111|35=3|34=350|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=343|58=SendingTime > > accuracy problem|372=1|373=10|10=233| > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=349|52=20030724-06:36:35|7=343|16=0|10=170| > > > > > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! SiteBuilder - Free, easy-to-use web site > > design software > > http://sitebuilder.yahoo.com > > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by: Free pre-built > > ASP.NET sites including > > Data Reports, E-commerce, Portals, and Forums are > > available now. > > Download today and enter to win an XBOX or Visual > > Studio .NET. > > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > > _______________________________________________ > > Quickfix-developers mailing list > > Qui...@li... > > > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site > design software > http://sitebuilder.yahoo.com > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built > ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are > available now. > Download today and enter to win an XBOX or Visual > Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Patrick R. <pat...@ya...> - 2003-07-24 16:45:03
|
Dont know, havent looked at it. QuickFix apparently is sending that to us(guess not), or maybe the client's app ?... I agree though : strange reject messages. I am trying to figure out the resend issue first, I'll see about the app complaining later on (not too late !) --- Oren Miller <ore...@ya...> wrote: > What's with all the SendingTime Accuracy problems? > > --- Patrick Reuter <pat...@ya...> wrote: > > We have some bad networking issues with a Client > > using > > QuickFix (1.5) > > > > Have a look at the log below (sorry for the > size..) > > we are in a bad loop. > > Let me know if you can make sense of it. > > > > It happened many times the same day, always the > same > > problem of FIX engine asking resend to each other, > > even if it does get more complicated as the day > went > > by... below is just the beginning of the problem. > > The > > thing I dont like though, is that our server sends > > the > > resend request first (!) and the client > answers/ask > > a > > resend with a sequence number that is not the one > we > > requested in the resend request - so we're stuck. > > > > > > > > > > > > FINE > > Sending : > > > 8=FIX.4.2|9=59|35=0|49=CLIENTTARGET|56=CLIENTSEND|34=337|52=20030724-06:35:05|10=196| > > Receiving : > > > 8=FIX.4.2|9=59|35=0|34=339|49=CLIENTSEND|52=20030724-06:35:28|56=CLIENTTARGET|10=203| > > Sending : > > > 8=FIX.4.2|9=59|35=0|49=CLIENTTARGET|56=CLIENTSEND|34=338|52=20030724-06:35:35|10=200| > > Sending : > > > 8=FIX.4.2|9=82|35=1|49=CLIENTTARGET|56=CLIENTSEND|34=339|52=20030724-06:36:00|112=HeartBtExt > > Timeout|10=115| > > Receiving : > > > 8=FIX.4.2|9=111|35=3|34=340|49=CLIENTSEND|52=20030724-06:31:15|56=CLIENTTARGET|45=339|58=SendingTime > > accuracy problem|372=1|373=10|10=238|^M > > > > Login OUT ok > > Receiving : > > > 8=FIX.4.2|9=59|35=5|34=341|49=CLIENTSEND|52=20030724-06:31:15|56=CLIENTTARGET|10=193|^M > > Sending : > > > 8=FIX.4.2|9=81|35=5|49=CLIENTTARGET|56=CLIENTSEND|34=340|52=20030724-06:36:00|58=Replying > > to logout|10=108|^M > > > > Login IN OK > > Receiving : > > > 8=FIX.4.2|9=71|35=A|34=342|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|98=0|108=30|10=224| > > Sending : > > > 8=FIX.4.2|9=71|35=A|49=CLIENTTARGET|56=CLIENTSEND|34=341|52=20030724-06:36:35|98=0|108=30|10=231| > > > > Server Receives 344 (where is 343?) > > Receiving : > > > 8=FIX.4.2|9=59|35=5|34=344|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=195| > > Server Resend request for 343 > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=342|52=20030724-06:36:35|7=343|16=0|10=163| > > Client Resend request for 340 (that was the logout > > answer above) ?? + asks that with 345, not 343 we > > requested > > -> we loop and hit a dead end... > > Receiving : > > > 8=FIX.4.2|9=72|35=2|34=345|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|7=340|16=340|10=004| > > Sending : > > > 8=FIX.4.2|9=77|35=4|49=CLIENTTARGET|56=CLIENTSEND|34=340|52=20030724-06:36:35|43=Y|123=Y|36=341|10=048| > > Sending : > > > 8=FIX.4.2|9=77|35=1|49=CLIENTTARGET|56=CLIENTSEND|34=343|52=20030724-06:36:35|112=synchronized?|10=247| > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=344|52=20030724-06:36:35|7=343|16=0|10=165| > > Receiving : > > > 8=FIX.4.2|9=111|35=3|34=346|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=342|58=SendingTime > > accuracy problem|372=2|373=10|10=238| > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=345|52=20030724-06:36:35|7=343|16=0|10=166| > > Receiving : > > > 8=FIX.4.2|9=59|35=5|34=347|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=198| > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=346|52=20030724-06:36:35|7=343|16=0|10=167| > > Receiving : > > > 8=FIX.4.2|9=111|35=3|34=348|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=340|58=SendingTime > > accuracy problem|372=4|373=10|10=240| > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=347|52=20030724-06:36:35|7=343|16=0|10=168| > > Receiving : > > > 8=FIX.4.2|9=59|35=5|34=349|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=200| > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=348|52=20030724-06:36:35|7=343|16=0|10=169| > > Receiving : > > > 8=FIX.4.2|9=111|35=3|34=350|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=343|58=SendingTime > > accuracy problem|372=1|373=10|10=233| > > Sending : > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=349|52=20030724-06:36:35|7=343|16=0|10=170| > > > > > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! SiteBuilder - Free, easy-to-use web site > > design software > > http://sitebuilder.yahoo.com > > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by: Free pre-built > > ASP.NET sites including > > Data Reports, E-commerce, Portals, and Forums are > > available now. > > Download today and enter to win an XBOX or Visual > > Studio .NET. > > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > > _______________________________________________ > > Quickfix-developers mailing list > > Qui...@li... > > > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site > design software > http://sitebuilder.yahoo.com > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built > ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are > available now. > Download today and enter to win an XBOX or Visual > Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Oren M. <ore...@ya...> - 2003-07-24 17:05:14
|
Well the default behavior of QuickFIX is to reject messages that have timestamps older than 2 minutes (as per the spec) This can be turned off or configured to some other value. I would recommend that you fix this first before looking at resend issues because this may be complicated your problems. You can either tell your counterparty to turn this feature off or figure out why the timestamps are out of whack. It looks like your clocks are 4 minutes apart, so you may want to just synchronize your clocks. BTW, looks you were having some resend issues with your last post :) --- Patrick Reuter <pat...@ya...> wrote: > Dont know, havent looked at it. > QuickFix apparently is sending that to us(guess > not), > or maybe the client's app ?... > I agree though : strange reject messages. > > I am trying to figure out the resend issue first, > I'll > see about the app complaining later on (not too late > !) > > > --- Oren Miller <ore...@ya...> wrote: > > What's with all the SendingTime Accuracy problems? > > > > --- Patrick Reuter <pat...@ya...> > wrote: > > > We have some bad networking issues with a Client > > > using > > > QuickFix (1.5) > > > > > > Have a look at the log below (sorry for the > > size..) > > > we are in a bad loop. > > > Let me know if you can make sense of it. > > > > > > It happened many times the same day, always the > > same > > > problem of FIX engine asking resend to each > other, > > > even if it does get more complicated as the day > > went > > > by... below is just the beginning of the > problem. > > > The > > > thing I dont like though, is that our server > sends > > > the > > > resend request first (!) and the client > > answers/ask > > > a > > > resend with a sequence number that is not the > one > > we > > > requested in the resend request - so we're > stuck. > > > > > > > > > > > > > > > > > > FINE > > > Sending : > > > > > > 8=FIX.4.2|9=59|35=0|49=CLIENTTARGET|56=CLIENTSEND|34=337|52=20030724-06:35:05|10=196| > > > Receiving : > > > > > > 8=FIX.4.2|9=59|35=0|34=339|49=CLIENTSEND|52=20030724-06:35:28|56=CLIENTTARGET|10=203| > > > Sending : > > > > > > 8=FIX.4.2|9=59|35=0|49=CLIENTTARGET|56=CLIENTSEND|34=338|52=20030724-06:35:35|10=200| > > > Sending : > > > > > > 8=FIX.4.2|9=82|35=1|49=CLIENTTARGET|56=CLIENTSEND|34=339|52=20030724-06:36:00|112=HeartBtExt > > > Timeout|10=115| > > > Receiving : > > > > > > 8=FIX.4.2|9=111|35=3|34=340|49=CLIENTSEND|52=20030724-06:31:15|56=CLIENTTARGET|45=339|58=SendingTime > > > accuracy problem|372=1|373=10|10=238|^M > > > > > > Login OUT ok > > > Receiving : > > > > > > 8=FIX.4.2|9=59|35=5|34=341|49=CLIENTSEND|52=20030724-06:31:15|56=CLIENTTARGET|10=193|^M > > > Sending : > > > > > > 8=FIX.4.2|9=81|35=5|49=CLIENTTARGET|56=CLIENTSEND|34=340|52=20030724-06:36:00|58=Replying > > > to logout|10=108|^M > > > > > > Login IN OK > > > Receiving : > > > > > > 8=FIX.4.2|9=71|35=A|34=342|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|98=0|108=30|10=224| > > > Sending : > > > > > > 8=FIX.4.2|9=71|35=A|49=CLIENTTARGET|56=CLIENTSEND|34=341|52=20030724-06:36:35|98=0|108=30|10=231| > > > > > > Server Receives 344 (where is 343?) > > > Receiving : > > > > > > 8=FIX.4.2|9=59|35=5|34=344|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=195| > > > Server Resend request for 343 > > > Sending : > > > > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=342|52=20030724-06:36:35|7=343|16=0|10=163| > > > Client Resend request for 340 (that was the > logout > > > answer above) ?? + asks that with 345, not 343 > we > > > requested > > > -> we loop and hit a dead end... > > > Receiving : > > > > > > 8=FIX.4.2|9=72|35=2|34=345|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|7=340|16=340|10=004| > > > Sending : > > > > > > 8=FIX.4.2|9=77|35=4|49=CLIENTTARGET|56=CLIENTSEND|34=340|52=20030724-06:36:35|43=Y|123=Y|36=341|10=048| > > > Sending : > > > > > > 8=FIX.4.2|9=77|35=1|49=CLIENTTARGET|56=CLIENTSEND|34=343|52=20030724-06:36:35|112=synchronized?|10=247| > > > Sending : > > > > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=344|52=20030724-06:36:35|7=343|16=0|10=165| > > > Receiving : > > > > > > 8=FIX.4.2|9=111|35=3|34=346|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=342|58=SendingTime > > > accuracy problem|372=2|373=10|10=238| > > > Sending : > > > > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=345|52=20030724-06:36:35|7=343|16=0|10=166| > > > Receiving : > > > > > > 8=FIX.4.2|9=59|35=5|34=347|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=198| > > > Sending : > > > > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=346|52=20030724-06:36:35|7=343|16=0|10=167| > > > Receiving : > > > > > > 8=FIX.4.2|9=111|35=3|34=348|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=340|58=SendingTime > > > accuracy problem|372=4|373=10|10=240| > > > Sending : > > > > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=347|52=20030724-06:36:35|7=343|16=0|10=168| > > > Receiving : > > > > > > 8=FIX.4.2|9=59|35=5|34=349|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|10=200| > > > Sending : > > > > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=348|52=20030724-06:36:35|7=343|16=0|10=169| > > > Receiving : > > > > > > 8=FIX.4.2|9=111|35=3|34=350|49=CLIENTSEND|52=20030724-06:31:50|56=CLIENTTARGET|45=343|58=SendingTime > > > accuracy problem|372=1|373=10|10=233| > > > Sending : > > > > > > 8=FIX.4.2|9=70|35=2|49=CLIENTTARGET|56=CLIENTSEND|34=349|52=20030724-06:36:35|7=343|16=0|10=170| > > > > > > > > > > > > __________________________________ > > > Do you Yahoo!? > > > Yahoo! SiteBuilder - Free, easy-to-use web site > > > design software > > > http://sitebuilder.yahoo.com > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email sponsored by: Free pre-built > > > ASP.NET sites including > > > Data Reports, E-commerce, Portals, and Forums > are > > > available now. > > > Download today and enter to win an XBOX or > Visual > > > Studio .NET. > > > > > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > > > _______________________________________________ > > > Quickfix-developers mailing list > > > Qui...@li... > > > > > > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > === message truncated === __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: James D. <jc...@co...> - 2003-07-24 22:45:42
|
Aside from the length of the ClOrdID some exchanges (CBOE comes to mind) requires a specific format. Jim =20 James C. Downs Connamara Systems, LLC 53 W. Jackson Blvd Suite 1627 Chicago, IL 60604 312 - 282 - 7746 www.connamara.com -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of = Oren Miller Sent: Thursday, July 24, 2003 10:32 AM To: Andrew Munn; qui...@li... Subject: Re: [Quickfix-developers] ClOrdID protocol?? There is no standard protocol for this. In fact, some exchanges won't = even look at it, they often treat it as a pass thru value. Generally, you = just need to insure somehow that it is unique for the extent of the session. Whatever way you choose to do that is entirely up to you. One thing you should verify is the maximum length your counterparty supports. Although there is no restriction on the length of a FIX = field, the counterparty usually stores this value in a database which forces a length restriction on their end. If their length restriction is hig = enough, you can use a UUID. Otherwise time + counter could be sufficient.=20 Or simply persisting somewhere the last id that you used. --- Andrew Munn <an...@nm...> wrote: > If a client program uses a simple counter to > generate Order IDs and the > client exits and then restarts, the ClOrdID is reset > to 1. Orders sent > after that get a "duplicate ClOrdID" reject until > more orders are sent > than were sent by the previous session (when new > ClOrdIDs start being > generated). >=20 > What is the standard procedure, if any, to ensure > uniqueness of ClOrdIDs > between disconnects, crashes, etc? Should an OMS > query the message > store on startup for the highest ClOrdID used that > day and begin > incrementing it? Should it assure uniqueness by > appending a session > counter to the end of the ID? Should it simply tack > on time&date? >=20 >=20 > Thanks > Andrew Munn > and...@ho... >=20 >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built > ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are > available now. > Download today and enter to win an XBOX or Visual > Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/= 01 > _______________________________________________ > Quickfix-developers mailing list=20 > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including = Data Reports, E-commerce, Portals, and Forums are available now. Download = today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/= 01 _______________________________________________ Quickfix-developers mailing list = Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Jo J. <jo...@tr...> - 2003-07-25 12:35:31
|
This is an issue I have been thinking about as well - I am planning to use a clordid that is 16 characters. Does anyone know of a destination that would not support an id of at least this length?? Presently, we route to NYSE, various nasdaq ecn's, and all 5 options exchanges. If someone has had an experience where 16 chars was too many, let me know. Thanks! Jo -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Oren Miller Sent: Thursday, July 24, 2003 10:32 To: Andrew Munn; qui...@li... Subject: Re: [Quickfix-developers] ClOrdID protocol?? There is no standard protocol for this. In fact, some exchanges won't even look at it, they often treat it as a pass thru value. Generally, you just need to insure somehow that it is unique for the extent of the session. Whatever way you choose to do that is entirely up to you. One thing you should verify is the maximum length your counterparty supports. Although there is no restriction on the length of a FIX field, the counterparty usually stores this value in a database which forces a length restriction on their end. If their length restriction is hig enough, you can use a UUID. Otherwise time + counter could be sufficient. Or simply persisting somewhere the last id that you used. --- Andrew Munn <an...@nm...> wrote: > If a client program uses a simple counter to > generate Order IDs and the > client exits and then restarts, the ClOrdID is reset > to 1. Orders sent > after that get a "duplicate ClOrdID" reject until > more orders are sent > than were sent by the previous session (when new > ClOrdIDs start being > generated). > > What is the standard procedure, if any, to ensure > uniqueness of ClOrdIDs > between disconnects, crashes, etc? Should an OMS > query the message > store on startup for the highest ClOrdID used that > day and begin > incrementing it? Should it assure uniqueness by > appending a session > counter to the end of the ID? Should it simply tack > on time&date? > > > Thanks > Andrew Munn > and...@ho... > > > > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built > ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are > available now. > Download today and enter to win an XBOX or Visual > Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 _______________________________________________ Quickfix-developers mailing list Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Joerg T. <Joe...@ma...> - 2003-07-25 14:56:21
|
Jo Janssens wrote: > This is an issue I have been thinking about as well - I am planning to > use a clordid that is 16 characters. Does anyone know of a destination > that would not support an id of at least this length?? Presently, we > route to NYSE, various nasdaq ecn's, and all 5 options exchanges. I can confirm that the Bank_Internal_Reference field of the Swiss Exchange (http://www.swx.com) and the virt-X (http://www.virt-x.com) is 16 chars long. This field is passed through from the order to the matching trades so that it may be taken as some sort of ClOrdID field. Just if anybody cares... Jo"rg -- Joerg Thoennes http://macd.com Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen |
|
From: James D. <jc...@co...> - 2003-07-26 01:48:15
|
I think Island has a 10 character max len, and CBOE requires a specific format. Jim =20 James C. Downs Connamara Systems, LLC 53 W. Jackson Blvd Suite 1627 Chicago, IL 60604 312 - 282 - 7746 www.connamara.com -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of Jo Janssens Sent: Friday, July 25, 2003 7:36 AM To: qui...@li... Subject: RE: [Quickfix-developers] ClOrdID protocol?? This is an issue I have been thinking about as well - I am planning to = use a clordid that is 16 characters. Does anyone know of a destination that = would not support an id of at least this length?? Presently, we route to NYSE, various nasdaq ecn's, and all 5 options exchanges. If someone has had an experience where 16 chars was too many, let me = know. Thanks! Jo -----Original Message----- From: qui...@li... [mailto:qui...@li...] On Behalf Of = Oren Miller Sent: Thursday, July 24, 2003 10:32 To: Andrew Munn; qui...@li... Subject: Re: [Quickfix-developers] ClOrdID protocol?? There is no standard protocol for this. In fact, some exchanges won't = even look at it, they often treat it as a pass thru value. Generally, you = just need to insure somehow that it is unique for the extent of the session. Whatever way you choose to do that is entirely up to you. One thing you should verify is the maximum length your counterparty supports. Although there is no restriction on the length of a FIX = field, the counterparty usually stores this value in a database which forces a length restriction on their end. If their length restriction is hig = enough, you can use a UUID. Otherwise time + counter could be sufficient.=20 Or simply persisting somewhere the last id that you used. --- Andrew Munn <an...@nm...> wrote: > If a client program uses a simple counter to > generate Order IDs and the > client exits and then restarts, the ClOrdID is reset > to 1. Orders sent > after that get a "duplicate ClOrdID" reject until > more orders are sent > than were sent by the previous session (when new > ClOrdIDs start being > generated). >=20 > What is the standard procedure, if any, to ensure > uniqueness of ClOrdIDs > between disconnects, crashes, etc? Should an OMS > query the message > store on startup for the highest ClOrdID used that > day and begin > incrementing it? Should it assure uniqueness by > appending a session > counter to the end of the ID? Should it simply tack > on time&date? >=20 >=20 > Thanks > Andrew Munn > and...@ho... >=20 >=20 >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built > ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are > available now. > Download today and enter to win an XBOX or Visual > Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 > _______________________________________________ > Quickfix-developers mailing list=20 > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including = Data Reports, E-commerce, Portals, and Forums are available now. Download = today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 /01 _______________________________________________ Quickfix-developers mailing list = Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including = Data Reports, E-commerce, Portals, and Forums are available now. Download = today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/= 01 _______________________________________________ Quickfix-developers mailing list = Qui...@li... https://lists.sourceforge.net/lists/listinfo/quickfix-developers |
|
From: Patrick R. <pat...@ya...> - 2003-07-26 03:30:09
|
F&O markets are difficult, few use FIX (CME for example), most have specific APIs. F&O brokers begin to develop FIX interface/gateways to their systems though. --- James Downs <jc...@co...> wrote: > I think Island has a 10 character max len, and CBOE > requires a specific > format. > > Jim > > James C. Downs > Connamara Systems, LLC > 53 W. Jackson Blvd > Suite 1627 > Chicago, IL 60604 > 312 - 282 - 7746 > www.connamara.com > > > -----Original Message----- > From: > qui...@li... > [mailto:qui...@li...] > On Behalf Of Jo > Janssens > Sent: Friday, July 25, 2003 7:36 AM > To: qui...@li... > Subject: RE: [Quickfix-developers] ClOrdID > protocol?? > > > This is an issue I have been thinking about as well > - I am planning to use a > clordid that is 16 characters. Does anyone know of a > destination that would > not support an id of at least this length?? > Presently, we route to NYSE, > various nasdaq ecn's, and all 5 options exchanges. > > If someone has had an experience where 16 chars was > too many, let me know. > > Thanks! > Jo > > -----Original Message----- > From: > qui...@li... > [mailto:qui...@li...] > On Behalf Of Oren > Miller > Sent: Thursday, July 24, 2003 10:32 > To: Andrew Munn; > qui...@li... > Subject: Re: [Quickfix-developers] ClOrdID > protocol?? > > There is no standard protocol for this. In fact, > some exchanges won't even > look at it, they often treat it as a pass thru > value. Generally, you just > need to insure somehow that it is unique for the > extent of the session. > Whatever way you choose to do that is entirely up to > you. > > One thing you should verify is the maximum length > your counterparty > supports. Although there is no restriction on the > length of a FIX field, > the counterparty usually stores this value in a > database which forces a > length restriction on their end. If their length > restriction is hig enough, > you can use a UUID. Otherwise time + counter could > be sufficient. > Or simply persisting somewhere the last id that you > used. > > --- Andrew Munn <an...@nm...> wrote: > > If a client program uses a simple counter to > > generate Order IDs and the > > client exits and then restarts, the ClOrdID is > reset > > to 1. Orders sent > > after that get a "duplicate ClOrdID" reject until > > more orders are sent > > than were sent by the previous session (when new > > ClOrdIDs start being > > generated). > > > > What is the standard procedure, if any, to ensure > > uniqueness of ClOrdIDs > > between disconnects, crashes, etc? Should an OMS > > query the message > > store on startup for the highest ClOrdID used that > > day and begin > > incrementing it? Should it assure uniqueness by > > appending a session > > counter to the end of the ID? Should it simply > tack > > on time&date? > > > > > > Thanks > > Andrew Munn > > and...@ho... > > > > > > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email sponsored by: Free pre-built > > ASP.NET sites including > > Data Reports, E-commerce, Portals, and Forums are > > available now. > > Download today and enter to win an XBOX or Visual > > Studio .NET. > > > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 > /01 > > _______________________________________________ > > Quickfix-developers mailing list > > Qui...@li... > > > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site > design software > http://sitebuilder.yahoo.com > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built > ASP.NET sites including Data > Reports, E-commerce, Portals, and Forums are > available now. Download today > and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01 > /01 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built > ASP.NET sites including Data > Reports, E-commerce, Portals, and Forums are > available now. Download today > and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built > ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are > available now. > Download today and enter to win an XBOX or Visual > Studio .NET. > http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 > _______________________________________________ > Quickfix-developers mailing list > Qui...@li... > https://lists.sourceforge.net/lists/listinfo/quickfix-developers __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Andrew M. <an...@nm...> - 2003-07-27 01:57:06
|
http://quickfix.thoughtworks.com/quickfix/doc/html/application.html says: "onCreate gets called when quickfix creates a new session. A session comes into and remains in existence for the life of the application. Sessions exist despite whether a counter party is connected to it. As soon as a session is created, you can begin sending messages to it. If no one is logged on, the messages will be sent at the time a connection is established with the counterparty." ...but this doesn't seem to be the case. If I send messages to a counterparty who is not yet connected, MsgSeqNum will reflect those messages having been sent, but they will not be saved in the store. So when that counterparty does connect, looks at the MsgSeqNum and sends a ResendRequest, the messages aren't available to send. Any suggestions on this? -Andrew Munn |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X