Steve (guest)
 |
| 07/21/2008 4:09 PM |
 Quote
 Reply
 Alert
|
I don't believe question 3 in the original post was answered yet:
********
3. In the PDP header, the "NumBodyEntries" field is,
"The number of times the message body repeats in the message. For example, if the body consists of a field (named Volume) and the “NumBodyEntries” field is 2, the number of bytes in the message body will be 8."
Please what is the "message body" here? What fields exactly are repeated and where?
********
I am confused by the wording in the Spec (1.4) as well. What fields are repeating exactly, or would this mean that one header may contain many instances of the same type of message? What is an example scenario where the NumBodyEntries > 1?
Thank You |
|
|
|
|
OBU - Support (guest)
|
| 07/22/2008 8:45 PM |
Quote
Reply
Alert
|
We are building a depth of book feed using OpenBook Ultra. We see no gaps in the Line Sequence or Symbol Sequence Numbers. However we see that when we build our book its crossed. The crosses eventually go away (after a few 100 milli seconds or so), but why is this happening. Is there anybody here who has successfully built an order book from Opepn Book Ultra Feed.
Thank you. |
|
|
|
|
herbg (guest)
|
| 07/31/2008 2:05 AM |
Quote
Reply
Alert
|
I am using data I collected on 7/28/09 . I see duplicate symbol sequence numbers for the same symbol. I have examined the orders and they are all different.
1 of 1, retrans: 1, linkFlag: 0, Symbol: AXL, LSN: 445722, SSN: 2996, previous SSN: 2995, sourceSessionID: 1
1 of 1, retrans: 1, linkFlag: 0, Symbol: AXL, LSN: 445723, SSN: 2996, previous SSN: 2996, sourceSessionID: 1
1 of 1, retrans: 1, linkFlag: 0, Symbol: AXL, LSN: 445724, SSN: 2996, previous SSN: 2996, sourceSessionID: 1
1 of 1, retrans: 1, linkFlag: 0, Symbol: AXL, LSN: 445725, SSN: 2996, previous SSN: 2996, sourceSessionID: 1
How should I proceed? |
|
|
|
|
Lydia
Posts:68
|
| 08/05/2008 11:42 AM |
Quote
Reply
Alert
|
Thank you for your inquiries. We will respond shortly.
Regards,
NYX Data Team |
|
|
|
|
Kenny
Posts:2
|
| 08/05/2008 1:53 PM |
Quote
Reply
Alert
|
| We're also seeing the same thing here. |
|
|
|
|
herbg (guest)
|
| 09/13/2008 12:06 AM |
Quote
Reply
Alert
|
I finally got the request lines working via my data provider. Now the rubber hits the road and I am trying to correlate my requests with the responses I see.
1) I found that if I set the msgSeqNum in the request, it is sent back to me as the sourceSeqNum in the TCP Retransmission Response,
2) I find that oftern get multiple responses back on either the primary request line or secondary request line from a single request to both? What's up with that? Why should I see multiple TCP responses to a single request?
3) How do I correlate the TCP response that the request was accepted with the multicast UPD response(s) I receive? |
|
|
|
|
cae (guest)
|
| 10/17/2008 2:22 PM |
Quote
Reply
Alert
|
As of 17 Oct 2008 I am seeing this as well.
ReasonCodes of 0x00 (not valid according to the spec) and per-symbol sequence numbers (SourceSeqNum) increasing in steps greater than 1 with no gaps in the outer MsgSeqNum.
Is anyone working on fixing this feed?
|
|
|
|
|
alh (guest)
|
| 10/23/2008 11:17 AM |
Quote
Reply
Alert
|
| Oct. 23 and still seeing per-symbol sequence numbers (SourceSeqNum) increasing in steps greater than 1 with no gaps in the outer MsgSeqNum |
|
|
|
|
John (guest)
|
| 10/28/2008 12:15 PM |
Quote
Reply
Alert
|
Some of the cancel and execution messages have a value, zero, for the "chgQty" field.
Is it possible to have zero values in that field? |
|
|
|
|
devfr (guest) (guest)
|
| 10/29/2008 10:23 AM |
Quote
Reply
Alert
|
| Every morning when we request full refreshes for all symbols they are crossed pretty much all the time. When market opens up they remain crossed and the book won't clear up. If I restart my app after the open I don't have this issue. I am not sure if I have missed anything from the spec regarding delta processing. Can anyone think of a reason why this could happen? |
|
|
|
|
Guest (guest)
|
| 11/05/2008 4:24 PM |
Quote
Reply
Alert
|
Hi.
We have collected some data from "real time" Openbook and from Ultra and cannot reconcile the data.
At the open things generally line up, but after that the books seem to diverge.
I am seeing much smaller volumes in Ultra (e.g. 100 lots on Ultra but 500 lots on Openbook).
My understanding is that Ultra has all limit orders (including floor interest) but RealTime Openbook does not contain floor interest, so Ultra should always show larger volumes than Openbook. These are not small short lived differences, they are long lived.
Can anyone think what I am doing wrong? Or is there some other order type that shows up on Openbook but not on Ultra?
|
|
|
|
|
herbg (guest)
|
| 11/14/2008 11:45 AM |
Quote
Reply
Alert
|
I posted a query on 7/31/2008 about what I should do when PDP Delta Update messages contains the duplicate sSN (symbol sequence numbers). I am looking for guidance on how to proceed in the presence of this condition. It appears that I can't ignore them, because this causes book exceptions later on, ie, please delete a price level for which I have no prior knowledge. Can I consider it non-fatal and just process the packet quietly? Should I post a log message indicating that I am processing a duplicate sSN?
I ran for quite some time and was not seeing this behavior so I assumed that the NYX Data Team had solved the issue. Because of this assumption, I put the strict processing rules back in place; (sSN must increase by 1 on each message packet, if sSN <= sSN_previous, ignore the duplicate record). This was clearly the wrong thing to do, as the data I collected on 11/07/2008 has 436 instances where the sSN is same, the line sequence number is different and the data contained in the packets with duplicate sSN is different (AND appears that I should be processing it). |
|
|
|
|
herbg (guest)
|
| 11/20/2008 9:14 PM |
Quote
Reply
Alert
|
| I am getting unsolicited responses from the TCP retransmission request lines. I captured the data using tcpdump and can clearly see amidst the Heartbeat Request / Heartbeat Response message an occassion Retransmission Response message, but there is no corresponding Request message in the trace. Is anyone else seeing this behavior? Right now I have logic to log and ignore unsolicted responses |
|
|
|
|
thisoneguy (guest)
|
| 11/21/2008 9:00 PM |
Quote
Reply
Alert
|
hi there, would we be able to tell from the openbook feed whether a quote was placed by a floor broker, DMM, SLP or a customer order (via DOT)?
cheers |
|
|
|
|
herbg (guest)
|
| 12/14/2008 1:42 AM |
Quote
Reply
Alert
|
| I got closure on this one. It has to do with how NYSE handles requests which is not necessaryily based on the connection that made the request but based on the source ID that is provided with the request. I has a single source ID for both the primary and secondary re-request lines and I was occassionly getting a response on for a request made on the primary line on the secondary line. So 1), never just get a single source ID and 2) always make sure the response contains the source ID you sent. |
|
|
|
|