|
FAST Protocol
< Previous Next >
Re: FAST Complaints
Rolf Andersson / Pantor Engineering
27 Jan 2010 4:25AM ET Brandon,
your point is valid and I don't think your comments have offended anyone. We actually had the tid before the pmap in one of our test versions of the protocol during development back in 2005. Then we found that on some actual live data (ARCA if I recall correctly), we could save 5-10% of the transfer size. So we decided to put the tid after the pmap, thus being able to use copy coding. This decision was based on our empirical tests, and I believe that we were able to show that this arrangement had a marginal impact on performance.
Best,
Rolf
> I'm resigning trying to explain my point. It doesn't seem like anyone
> wants to actually read what I'm saying. I was honestly trying to help
> the protocol be more efficient so for anyone taking offense to my
> comments please don't.
>
> Oh and for the record I have not a clue what Majkara is talking about.
>
> Brandon
>
> > > That's why I was suggesting that if there is to be another FAST
> > > version, it might be a good update to move the template id to the
> > > beginning of the message and you can even set it to NULL if it is to
> > > be copied from a previous message.
> >
> > That doesn't make sense. A NULL value means the field is not present
> > in this record. The TID must be present.
> >
> > A zero PMAP bit for a field means the field is not present _on the
> > wire_. To answer your earlier question, "Yes there are FAST data
> > sources that omit the TID on the wire, relying on the implicit
> > copy operator for the template ID. For this to work, the PMAP must
> > come first.
> >
> > If this is a problem for your implementation, I might respectfully
> > suggest you change your implementation rather than trying to change
> > the protocol.
> >
> > Dale
Re: FAST Complaints
Rolf Andersson / Pantor Engineering 27 Jan 2010 4:25AM ET
|
