Imported from previous forum
Page 9 / 11 of Version 0.2 Scope definition Strawman document dated 15-Dec-2010 states :-
7.4.2 Language Bindings
Specific considerations/optimizations for applications written in C, C++, Java or other languages, use of data types and conversions between them.
? How does this affect the design of a new **Trading protocol (Name to be assigned after formal GTC approval 
?
? What programming languages would be considered for this optimization ?
As I understand, the protocol specification would only state “expect a stream of bytes which would be delimited into messages based on . Individual messages would be formatted as per <…> and uniquely identified as per <…> Messages c/sh/would be related to other messages exchanged as per <…> If do else if …”
Should not the protocol design be programming language / operating system / hardware independent ?
Regards,
K. Mahesh
[ original email was from John Harris - john.harris@bondmart.com ]
Mahesh,
I interpreted that section of the draft to be more of a question than a declaration - asking, in effect, what considerations/optimizations are applicable to the protocol-development effort.
As is obvious from my posts, I am not a developer, but I would guess there are legitimate considerations in this regard, even if the new protocol is intended to be feasible for implementation across a wide array of languages, operating systems, hardware, etc. If, for example, it is useful for the protocol to specify data types, then some consideration of languages is probably in order (for memory allocation reasons, etc.).
Best,
John
Page 9 / 11 of Version 0.2 Scope definition Strawman document dated 15-Dec-2010 states :-
7.4.2 Language Bindings
Specific considerations/optimizations for applications written in C, C++, Java or other languages, use of data types and conversions between them.
? How does this affect the design of a new **Trading protocol (Name to be assigned after formal GTC approval
?
? What programming languages would be considered for this optimization ?
As I understand, the protocol specification would only state “expect a stream of bytes which would be delimited into messages based on . Individual messages would be formatted as per <…> and uniquely identified as per <…> Messages c/sh/would be related to other messages exchanged as per <…> If do else if …”
Should not the protocol design be programming language / operating system / hardware independent ?
Regards,
K. Mahesh
Mahesh,
the protocol should certainly be independent of a specific environment, but given that we are aiming for high performance I believe there is good reason to keep an eye on the effects of the various protocol design decisions.
For example, we may go for little-endian (LE) rather than big-endian (BE) representation due to the ubiquity of the x86 platform. Choosing LE doesn’t exclude using the protocol in BE environments, it just requires an impl in a BE environment to perform byte-swapping on multi-byte binary quantities. The alternative would be to stick to the traditional BE orientation of most Internet protocols. It’s important from an interoperability point of view that we make sure that the protocol is well-defined re endianess.
Another example is the absence of unsigned integer types in Java.
/Rolf
Should not the protocol design be programming language / operating system / hardware independent ?