[jira] [Commented] (THRIFT-3867) Specify BinaryProtocol and CompactProtocol
[ https://issues.apache.org/jira/browse/THRIFT-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15358089#comment-15358089 ] ASF GitHub Bot commented on THRIFT-3867: Github user Jens-G commented on a diff in the pull request: https://github.com/apache/thrift/pull/1036#discussion_r69231154 --- Diff: doc/specs/thrift-binary-protocol-encoding.md --- @@ -0,0 +1,467 @@ +Thrift Protocol Encoding for BinaryProtocol and CompactProtocol + + +Last Modified: 2016-Jun-29 + +! WARNING ! + +This document is _work in progress_ and should not (yet) be seen as an authoritative source of information. + +This text is submitted to the Thrift community for review and improvements. + + + +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + + + +There are many ways to encode Thrift on the wire. This documents focuses on the wire encoding for services calls +(encoding and semantics) in the Thrift older *binary protocol* (which has not been documented before) and the +*compact protocol*. Both the regular socket transport (unframed) and the framed transport are described. + +Note that no effort is made to group descriptions of behavior of the Thrift server and the encodings used in the +Thrift wire format. The order in which things are described is such that you can read the document from top to bottom. + +The information here is mostly based on the Java implementation in the Apache thrift library (version 0.9.1) and +[THRIFT-110 A more compact format](https://issues.apache.org/jira/browse/THRIFT-110). Other implementation however, +should behave the same. + +## Message exchange + +Both the binary protocol and the compact protocol assume a transport layer that exposes a bi-directional byte stream, +for example a TCP socket. Both use the following message exchange: + +1. Client sends a `TMessage` (type `Call`). The TMessage contains some metadata and the name of the method to invoke. +2. Client sends method arguments (a struct defined by the generate code). +3. Server sends a `TMessage` (type `Response` or `Exception`) to start the response. +4. Server sends completes response with a struct (a predefined struct or one defined by generated code). + +The pattern is a simple half duplex protocol where the parties alternate in sending a `TMessage` followed by a struct. +What these are is described below. + +Although the standard Apache Thrift Java clients do not support pipelining (sending multiple requests without waiting +for an response), the standard Apache Thrift Java servers do support it. + +## TMessage + +A *TMessage* contains the following information: + +* _Message type_, a message types, one of `Call`, `Reply`, `Exception` and `Oneway`. +* _Sequence id_, an int32 integer. +* _Name_, a string (can be empty). + +The *sequence id* is a simple message id assigned by the client. The server will use the same sequence id in the +TMessage of the response. The client uses this number to detect out of order responses. Each client has a int32 field +which is increased for each message. The sequence id simply wraps around when it overflows. + +The *name* indicates the service method name to invoke. The server uses the same name in the TMessage of the response. + +When the *multiplexed protocol* is used, the name contains the service name, a colon `:` and the method name. The +multiplexed protocol is not compatible with other protocols. + +The *message type* indicates what kind of message is sent. + +Clients send requests with TMessages of type `Call` or `Oneway` (step 1 in the protocol exchange). Servers send +responses with TMessages of type `Exception` or `Reply`. + +### Oneway + +Type
[GitHub] thrift pull request #1036: THRIFT-3867 Specify BinaryProtocol and CompactPro...
Github user Jens-G commented on a diff in the pull request: https://github.com/apache/thrift/pull/1036#discussion_r69231154 --- Diff: doc/specs/thrift-binary-protocol-encoding.md --- @@ -0,0 +1,467 @@ +Thrift Protocol Encoding for BinaryProtocol and CompactProtocol + + +Last Modified: 2016-Jun-29 + +! WARNING ! + +This document is _work in progress_ and should not (yet) be seen as an authoritative source of information. + +This text is submitted to the Thrift community for review and improvements. + + + +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + + + +There are many ways to encode Thrift on the wire. This documents focuses on the wire encoding for services calls +(encoding and semantics) in the Thrift older *binary protocol* (which has not been documented before) and the +*compact protocol*. Both the regular socket transport (unframed) and the framed transport are described. + +Note that no effort is made to group descriptions of behavior of the Thrift server and the encodings used in the +Thrift wire format. The order in which things are described is such that you can read the document from top to bottom. + +The information here is mostly based on the Java implementation in the Apache thrift library (version 0.9.1) and +[THRIFT-110 A more compact format](https://issues.apache.org/jira/browse/THRIFT-110). Other implementation however, +should behave the same. + +## Message exchange + +Both the binary protocol and the compact protocol assume a transport layer that exposes a bi-directional byte stream, +for example a TCP socket. Both use the following message exchange: + +1. Client sends a `TMessage` (type `Call`). The TMessage contains some metadata and the name of the method to invoke. +2. Client sends method arguments (a struct defined by the generate code). +3. Server sends a `TMessage` (type `Response` or `Exception`) to start the response. +4. Server sends completes response with a struct (a predefined struct or one defined by generated code). + +The pattern is a simple half duplex protocol where the parties alternate in sending a `TMessage` followed by a struct. +What these are is described below. + +Although the standard Apache Thrift Java clients do not support pipelining (sending multiple requests without waiting +for an response), the standard Apache Thrift Java servers do support it. + +## TMessage + +A *TMessage* contains the following information: + +* _Message type_, a message types, one of `Call`, `Reply`, `Exception` and `Oneway`. +* _Sequence id_, an int32 integer. +* _Name_, a string (can be empty). + +The *sequence id* is a simple message id assigned by the client. The server will use the same sequence id in the +TMessage of the response. The client uses this number to detect out of order responses. Each client has a int32 field +which is increased for each message. The sequence id simply wraps around when it overflows. + +The *name* indicates the service method name to invoke. The server uses the same name in the TMessage of the response. + +When the *multiplexed protocol* is used, the name contains the service name, a colon `:` and the method name. The +multiplexed protocol is not compatible with other protocols. + +The *message type* indicates what kind of message is sent. + +Clients send requests with TMessages of type `Call` or `Oneway` (step 1 in the protocol exchange). Servers send +responses with TMessages of type `Exception` or `Reply`. + +### Oneway + +Type `Oneway` is only used starting from Apache Thrift 0.9.3. Earlier versions do _not_ send TMessages of type `Oneway`, +even for service methods defined with the `oneway` modifier. + +When client sends a request with type `Oneway`, the
[GitHub] thrift issue #1036: THRIFT-3867 Specify BinaryProtocol and CompactProtocol
Github user Jens-G commented on the issue: https://github.com/apache/thrift/pull/1036 Overall pretty neat. I still have a few complaints. 1. The document repeats a lot of stuff that can be found elsewhere, e.g. in the Thrift Whitepaper. There is nothing per se wrong with repeating stuff, but from my feeling it makes the spec a bit bloaty. 2. I think the structure should be revised grossly. No need to panic, I'm going to explain what I have in mind. By looking at the bits and bytes the reader may miss an important point: The order of data is always the same and entitrely Independent from the wire format, because that's the way Thrift Protocols work. * At the first level we have messages. They have a certain structure. * at the next level, a particular data item has a certain structure: a map always consists of two types and a count, plus the elements. That does not change between protocols. What changes is the way how a particular protocol organizes the data onto the wire. * and one level deeper we are at what I mean by revising the structure: I would not constantly jump back and forth between protocols to explain structs, lists, sets, integers, etc. Instead, there should be one chapter focusing on binary, and another one for compact. That makes it much easier a) for the reader who is usually interested in only one protocol at a time, and b) for future maintainers to add more protocols, such as JSON. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-3867) Specify BinaryProtocol and CompactProtocol
[ https://issues.apache.org/jira/browse/THRIFT-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357749#comment-15357749 ] ASF GitHub Bot commented on THRIFT-3867: Github user Jens-G commented on a diff in the pull request: https://github.com/apache/thrift/pull/1036#discussion_r69198940 --- Diff: doc/specs/thrift-binary-protocol-encoding.md --- @@ -0,0 +1,467 @@ +Thrift Protocol Encoding for BinaryProtocol and CompactProtocol + + +Last Modified: 2016-Jun-29 + +! WARNING ! + +This document is _work in progress_ and should not (yet) be seen as an authoritative source of information. + +This text is submitted to the Thrift community for review and improvements. + + + +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + + + +There are many ways to encode Thrift on the wire. This documents focuses on the wire encoding for services calls +(encoding and semantics) in the Thrift older *binary protocol* (which has not been documented before) and the +*compact protocol*. Both the regular socket transport (unframed) and the framed transport are described. + +Note that no effort is made to group descriptions of behavior of the Thrift server and the encodings used in the +Thrift wire format. The order in which things are described is such that you can read the document from top to bottom. + +The information here is mostly based on the Java implementation in the Apache thrift library (version 0.9.1) and +[THRIFT-110 A more compact format](https://issues.apache.org/jira/browse/THRIFT-110). Other implementation however, +should behave the same. + +## Message exchange + +Both the binary protocol and the compact protocol assume a transport layer that exposes a bi-directional byte stream, +for example a TCP socket. Both use the following message exchange: + +1. Client sends a `TMessage` (type `Call`). The TMessage contains some metadata and the name of the method to invoke. +2. Client sends method arguments (a struct defined by the generate code). +3. Server sends a `TMessage` (type `Response` or `Exception`) to start the response. +4. Server sends completes response with a struct (a predefined struct or one defined by generated code). + +The pattern is a simple half duplex protocol where the parties alternate in sending a `TMessage` followed by a struct. +What these are is described below. + +Although the standard Apache Thrift Java clients do not support pipelining (sending multiple requests without waiting +for an response), the standard Apache Thrift Java servers do support it. + +## TMessage + +A *TMessage* contains the following information: + +* _Message type_, a message types, one of `Call`, `Reply`, `Exception` and `Oneway`. +* _Sequence id_, an int32 integer. +* _Name_, a string (can be empty). + +The *sequence id* is a simple message id assigned by the client. The server will use the same sequence id in the +TMessage of the response. The client uses this number to detect out of order responses. Each client has a int32 field +which is increased for each message. The sequence id simply wraps around when it overflows. + +The *name* indicates the service method name to invoke. The server uses the same name in the TMessage of the response. + +When the *multiplexed protocol* is used, the name contains the service name, a colon `:` and the method name. The +multiplexed protocol is not compatible with other protocols. + +The *message type* indicates what kind of message is sent. + +Clients send requests with TMessages of type `Call` or `Oneway` (step 1 in the protocol exchange). Servers send +responses with TMessages of type `Exception` or `Reply`. + +### Oneway + +Type
[GitHub] thrift pull request #1036: THRIFT-3867 Specify BinaryProtocol and CompactPro...
Github user Jens-G commented on a diff in the pull request: https://github.com/apache/thrift/pull/1036#discussion_r69198940 --- Diff: doc/specs/thrift-binary-protocol-encoding.md --- @@ -0,0 +1,467 @@ +Thrift Protocol Encoding for BinaryProtocol and CompactProtocol + + +Last Modified: 2016-Jun-29 + +! WARNING ! + +This document is _work in progress_ and should not (yet) be seen as an authoritative source of information. + +This text is submitted to the Thrift community for review and improvements. + + + +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + + + +There are many ways to encode Thrift on the wire. This documents focuses on the wire encoding for services calls +(encoding and semantics) in the Thrift older *binary protocol* (which has not been documented before) and the +*compact protocol*. Both the regular socket transport (unframed) and the framed transport are described. + +Note that no effort is made to group descriptions of behavior of the Thrift server and the encodings used in the +Thrift wire format. The order in which things are described is such that you can read the document from top to bottom. + +The information here is mostly based on the Java implementation in the Apache thrift library (version 0.9.1) and +[THRIFT-110 A more compact format](https://issues.apache.org/jira/browse/THRIFT-110). Other implementation however, +should behave the same. + +## Message exchange + +Both the binary protocol and the compact protocol assume a transport layer that exposes a bi-directional byte stream, +for example a TCP socket. Both use the following message exchange: + +1. Client sends a `TMessage` (type `Call`). The TMessage contains some metadata and the name of the method to invoke. +2. Client sends method arguments (a struct defined by the generate code). +3. Server sends a `TMessage` (type `Response` or `Exception`) to start the response. +4. Server sends completes response with a struct (a predefined struct or one defined by generated code). + +The pattern is a simple half duplex protocol where the parties alternate in sending a `TMessage` followed by a struct. +What these are is described below. + +Although the standard Apache Thrift Java clients do not support pipelining (sending multiple requests without waiting +for an response), the standard Apache Thrift Java servers do support it. + +## TMessage + +A *TMessage* contains the following information: + +* _Message type_, a message types, one of `Call`, `Reply`, `Exception` and `Oneway`. +* _Sequence id_, an int32 integer. +* _Name_, a string (can be empty). + +The *sequence id* is a simple message id assigned by the client. The server will use the same sequence id in the +TMessage of the response. The client uses this number to detect out of order responses. Each client has a int32 field +which is increased for each message. The sequence id simply wraps around when it overflows. + +The *name* indicates the service method name to invoke. The server uses the same name in the TMessage of the response. + +When the *multiplexed protocol* is used, the name contains the service name, a colon `:` and the method name. The +multiplexed protocol is not compatible with other protocols. + +The *message type* indicates what kind of message is sent. + +Clients send requests with TMessages of type `Call` or `Oneway` (step 1 in the protocol exchange). Servers send +responses with TMessages of type `Exception` or `Reply`. + +### Oneway + +Type `Oneway` is only used starting from Apache Thrift 0.9.3. Earlier versions do _not_ send TMessages of type `Oneway`, +even for service methods defined with the `oneway` modifier. + +When client sends a request with type `Oneway`, the
[jira] [Commented] (THRIFT-3867) Specify BinaryProtocol and CompactProtocol
[ https://issues.apache.org/jira/browse/THRIFT-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357737#comment-15357737 ] ASF GitHub Bot commented on THRIFT-3867: Github user Jens-G commented on a diff in the pull request: https://github.com/apache/thrift/pull/1036#discussion_r69198205 --- Diff: doc/specs/thrift-binary-protocol-encoding.md --- @@ -0,0 +1,467 @@ +Thrift Protocol Encoding for BinaryProtocol and CompactProtocol + + +Last Modified: 2016-Jun-29 + +! WARNING ! + +This document is _work in progress_ and should not (yet) be seen as an authoritative source of information. + +This text is submitted to the Thrift community for review and improvements. + + + +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + + + +There are many ways to encode Thrift on the wire. This documents focuses on the wire encoding for services calls +(encoding and semantics) in the Thrift older *binary protocol* (which has not been documented before) and the +*compact protocol*. Both the regular socket transport (unframed) and the framed transport are described. + +Note that no effort is made to group descriptions of behavior of the Thrift server and the encodings used in the +Thrift wire format. The order in which things are described is such that you can read the document from top to bottom. + +The information here is mostly based on the Java implementation in the Apache thrift library (version 0.9.1) and +[THRIFT-110 A more compact format](https://issues.apache.org/jira/browse/THRIFT-110). Other implementation however, +should behave the same. + +## Message exchange + +Both the binary protocol and the compact protocol assume a transport layer that exposes a bi-directional byte stream, +for example a TCP socket. Both use the following message exchange: + +1. Client sends a `TMessage` (type `Call`). The TMessage contains some metadata and the name of the method to invoke. +2. Client sends method arguments (a struct defined by the generate code). +3. Server sends a `TMessage` (type `Response` or `Exception`) to start the response. +4. Server sends completes response with a struct (a predefined struct or one defined by generated code). + +The pattern is a simple half duplex protocol where the parties alternate in sending a `TMessage` followed by a struct. +What these are is described below. + +Although the standard Apache Thrift Java clients do not support pipelining (sending multiple requests without waiting +for an response), the standard Apache Thrift Java servers do support it. + +## TMessage + +A *TMessage* contains the following information: + +* _Message type_, a message types, one of `Call`, `Reply`, `Exception` and `Oneway`. +* _Sequence id_, an int32 integer. +* _Name_, a string (can be empty). + +The *sequence id* is a simple message id assigned by the client. The server will use the same sequence id in the +TMessage of the response. The client uses this number to detect out of order responses. Each client has a int32 field +which is increased for each message. The sequence id simply wraps around when it overflows. + +The *name* indicates the service method name to invoke. The server uses the same name in the TMessage of the response. + +When the *multiplexed protocol* is used, the name contains the service name, a colon `:` and the method name. The +multiplexed protocol is not compatible with other protocols. + +The *message type* indicates what kind of message is sent. + +Clients send requests with TMessages of type `Call` or `Oneway` (step 1 in the protocol exchange). Servers send +responses with TMessages of type `Exception` or `Reply`. + +### Oneway + +Type
[GitHub] thrift pull request #1036: THRIFT-3867 Specify BinaryProtocol and CompactPro...
Github user Jens-G commented on a diff in the pull request: https://github.com/apache/thrift/pull/1036#discussion_r69198205 --- Diff: doc/specs/thrift-binary-protocol-encoding.md --- @@ -0,0 +1,467 @@ +Thrift Protocol Encoding for BinaryProtocol and CompactProtocol + + +Last Modified: 2016-Jun-29 + +! WARNING ! + +This document is _work in progress_ and should not (yet) be seen as an authoritative source of information. + +This text is submitted to the Thrift community for review and improvements. + + + +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + + + +There are many ways to encode Thrift on the wire. This documents focuses on the wire encoding for services calls +(encoding and semantics) in the Thrift older *binary protocol* (which has not been documented before) and the +*compact protocol*. Both the regular socket transport (unframed) and the framed transport are described. + +Note that no effort is made to group descriptions of behavior of the Thrift server and the encodings used in the +Thrift wire format. The order in which things are described is such that you can read the document from top to bottom. + +The information here is mostly based on the Java implementation in the Apache thrift library (version 0.9.1) and +[THRIFT-110 A more compact format](https://issues.apache.org/jira/browse/THRIFT-110). Other implementation however, +should behave the same. + +## Message exchange + +Both the binary protocol and the compact protocol assume a transport layer that exposes a bi-directional byte stream, +for example a TCP socket. Both use the following message exchange: + +1. Client sends a `TMessage` (type `Call`). The TMessage contains some metadata and the name of the method to invoke. +2. Client sends method arguments (a struct defined by the generate code). +3. Server sends a `TMessage` (type `Response` or `Exception`) to start the response. +4. Server sends completes response with a struct (a predefined struct or one defined by generated code). + +The pattern is a simple half duplex protocol where the parties alternate in sending a `TMessage` followed by a struct. +What these are is described below. + +Although the standard Apache Thrift Java clients do not support pipelining (sending multiple requests without waiting +for an response), the standard Apache Thrift Java servers do support it. + +## TMessage + +A *TMessage* contains the following information: + +* _Message type_, a message types, one of `Call`, `Reply`, `Exception` and `Oneway`. +* _Sequence id_, an int32 integer. +* _Name_, a string (can be empty). + +The *sequence id* is a simple message id assigned by the client. The server will use the same sequence id in the +TMessage of the response. The client uses this number to detect out of order responses. Each client has a int32 field +which is increased for each message. The sequence id simply wraps around when it overflows. + +The *name* indicates the service method name to invoke. The server uses the same name in the TMessage of the response. + +When the *multiplexed protocol* is used, the name contains the service name, a colon `:` and the method name. The +multiplexed protocol is not compatible with other protocols. + +The *message type* indicates what kind of message is sent. + +Clients send requests with TMessages of type `Call` or `Oneway` (step 1 in the protocol exchange). Servers send +responses with TMessages of type `Exception` or `Reply`. + +### Oneway + +Type `Oneway` is only used starting from Apache Thrift 0.9.3. Earlier versions do _not_ send TMessages of type `Oneway`, +even for service methods defined with the `oneway` modifier. + +When client sends a request with type `Oneway`, the
[jira] [Commented] (THRIFT-3867) Specify BinaryProtocol and CompactProtocol
[ https://issues.apache.org/jira/browse/THRIFT-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357734#comment-15357734 ] ASF GitHub Bot commented on THRIFT-3867: Github user Jens-G commented on a diff in the pull request: https://github.com/apache/thrift/pull/1036#discussion_r69197727 --- Diff: doc/specs/thrift-binary-protocol-encoding.md --- @@ -0,0 +1,467 @@ +Thrift Protocol Encoding for BinaryProtocol and CompactProtocol + + +Last Modified: 2016-Jun-29 + +! WARNING ! + +This document is _work in progress_ and should not (yet) be seen as an authoritative source of information. + +This text is submitted to the Thrift community for review and improvements. + + + +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + + + +There are many ways to encode Thrift on the wire. This documents focuses on the wire encoding for services calls +(encoding and semantics) in the Thrift older *binary protocol* (which has not been documented before) and the +*compact protocol*. Both the regular socket transport (unframed) and the framed transport are described. + +Note that no effort is made to group descriptions of behavior of the Thrift server and the encodings used in the +Thrift wire format. The order in which things are described is such that you can read the document from top to bottom. + +The information here is mostly based on the Java implementation in the Apache thrift library (version 0.9.1) and +[THRIFT-110 A more compact format](https://issues.apache.org/jira/browse/THRIFT-110). Other implementation however, +should behave the same. + +## Message exchange + +Both the binary protocol and the compact protocol assume a transport layer that exposes a bi-directional byte stream, +for example a TCP socket. Both use the following message exchange: + +1. Client sends a `TMessage` (type `Call`). The TMessage contains some metadata and the name of the method to invoke. +2. Client sends method arguments (a struct defined by the generate code). +3. Server sends a `TMessage` (type `Response` or `Exception`) to start the response. +4. Server sends completes response with a struct (a predefined struct or one defined by generated code). + +The pattern is a simple half duplex protocol where the parties alternate in sending a `TMessage` followed by a struct. +What these are is described below. + +Although the standard Apache Thrift Java clients do not support pipelining (sending multiple requests without waiting +for an response), the standard Apache Thrift Java servers do support it. + +## TMessage + +A *TMessage* contains the following information: + +* _Message type_, a message types, one of `Call`, `Reply`, `Exception` and `Oneway`. +* _Sequence id_, an int32 integer. +* _Name_, a string (can be empty). + +The *sequence id* is a simple message id assigned by the client. The server will use the same sequence id in the +TMessage of the response. The client uses this number to detect out of order responses. Each client has a int32 field +which is increased for each message. The sequence id simply wraps around when it overflows. + +The *name* indicates the service method name to invoke. The server uses the same name in the TMessage of the response. + +When the *multiplexed protocol* is used, the name contains the service name, a colon `:` and the method name. The +multiplexed protocol is not compatible with other protocols. + +The *message type* indicates what kind of message is sent. + +Clients send requests with TMessages of type `Call` or `Oneway` (step 1 in the protocol exchange). Servers send +responses with TMessages of type `Exception` or `Reply`. + +### Oneway + +Type
[GitHub] thrift pull request #1036: THRIFT-3867 Specify BinaryProtocol and CompactPro...
Github user Jens-G commented on a diff in the pull request: https://github.com/apache/thrift/pull/1036#discussion_r69197727 --- Diff: doc/specs/thrift-binary-protocol-encoding.md --- @@ -0,0 +1,467 @@ +Thrift Protocol Encoding for BinaryProtocol and CompactProtocol + + +Last Modified: 2016-Jun-29 + +! WARNING ! + +This document is _work in progress_ and should not (yet) be seen as an authoritative source of information. + +This text is submitted to the Thrift community for review and improvements. + + + +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + + + +There are many ways to encode Thrift on the wire. This documents focuses on the wire encoding for services calls +(encoding and semantics) in the Thrift older *binary protocol* (which has not been documented before) and the +*compact protocol*. Both the regular socket transport (unframed) and the framed transport are described. + +Note that no effort is made to group descriptions of behavior of the Thrift server and the encodings used in the +Thrift wire format. The order in which things are described is such that you can read the document from top to bottom. + +The information here is mostly based on the Java implementation in the Apache thrift library (version 0.9.1) and +[THRIFT-110 A more compact format](https://issues.apache.org/jira/browse/THRIFT-110). Other implementation however, +should behave the same. + +## Message exchange + +Both the binary protocol and the compact protocol assume a transport layer that exposes a bi-directional byte stream, +for example a TCP socket. Both use the following message exchange: + +1. Client sends a `TMessage` (type `Call`). The TMessage contains some metadata and the name of the method to invoke. +2. Client sends method arguments (a struct defined by the generate code). +3. Server sends a `TMessage` (type `Response` or `Exception`) to start the response. +4. Server sends completes response with a struct (a predefined struct or one defined by generated code). + +The pattern is a simple half duplex protocol where the parties alternate in sending a `TMessage` followed by a struct. +What these are is described below. + +Although the standard Apache Thrift Java clients do not support pipelining (sending multiple requests without waiting +for an response), the standard Apache Thrift Java servers do support it. + +## TMessage + +A *TMessage* contains the following information: + +* _Message type_, a message types, one of `Call`, `Reply`, `Exception` and `Oneway`. +* _Sequence id_, an int32 integer. +* _Name_, a string (can be empty). + +The *sequence id* is a simple message id assigned by the client. The server will use the same sequence id in the +TMessage of the response. The client uses this number to detect out of order responses. Each client has a int32 field +which is increased for each message. The sequence id simply wraps around when it overflows. + +The *name* indicates the service method name to invoke. The server uses the same name in the TMessage of the response. + +When the *multiplexed protocol* is used, the name contains the service name, a colon `:` and the method name. The +multiplexed protocol is not compatible with other protocols. + +The *message type* indicates what kind of message is sent. + +Clients send requests with TMessages of type `Call` or `Oneway` (step 1 in the protocol exchange). Servers send +responses with TMessages of type `Exception` or `Reply`. + +### Oneway + +Type `Oneway` is only used starting from Apache Thrift 0.9.3. Earlier versions do _not_ send TMessages of type `Oneway`, +even for service methods defined with the `oneway` modifier. + +When client sends a request with type `Oneway`, the
[jira] [Commented] (THRIFT-3867) Specify BinaryProtocol and CompactProtocol
[ https://issues.apache.org/jira/browse/THRIFT-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357728#comment-15357728 ] ASF GitHub Bot commented on THRIFT-3867: Github user Jens-G commented on a diff in the pull request: https://github.com/apache/thrift/pull/1036#discussion_r69196978 --- Diff: doc/specs/thrift-binary-protocol-encoding.md --- @@ -0,0 +1,467 @@ +Thrift Protocol Encoding for BinaryProtocol and CompactProtocol + + +Last Modified: 2016-Jun-29 + +! WARNING ! + +This document is _work in progress_ and should not (yet) be seen as an authoritative source of information. + +This text is submitted to the Thrift community for review and improvements. + + + +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + + + +There are many ways to encode Thrift on the wire. This documents focuses on the wire encoding for services calls +(encoding and semantics) in the Thrift older *binary protocol* (which has not been documented before) and the +*compact protocol*. Both the regular socket transport (unframed) and the framed transport are described. + +Note that no effort is made to group descriptions of behavior of the Thrift server and the encodings used in the +Thrift wire format. The order in which things are described is such that you can read the document from top to bottom. + +The information here is mostly based on the Java implementation in the Apache thrift library (version 0.9.1) and +[THRIFT-110 A more compact format](https://issues.apache.org/jira/browse/THRIFT-110). Other implementation however, +should behave the same. + +## Message exchange + +Both the binary protocol and the compact protocol assume a transport layer that exposes a bi-directional byte stream, +for example a TCP socket. Both use the following message exchange: + +1. Client sends a `TMessage` (type `Call`). The TMessage contains some metadata and the name of the method to invoke. +2. Client sends method arguments (a struct defined by the generate code). +3. Server sends a `TMessage` (type `Response` or `Exception`) to start the response. +4. Server sends completes response with a struct (a predefined struct or one defined by generated code). + +The pattern is a simple half duplex protocol where the parties alternate in sending a `TMessage` followed by a struct. +What these are is described below. + +Although the standard Apache Thrift Java clients do not support pipelining (sending multiple requests without waiting +for an response), the standard Apache Thrift Java servers do support it. + +## TMessage + +A *TMessage* contains the following information: + +* _Message type_, a message types, one of `Call`, `Reply`, `Exception` and `Oneway`. +* _Sequence id_, an int32 integer. +* _Name_, a string (can be empty). + +The *sequence id* is a simple message id assigned by the client. The server will use the same sequence id in the +TMessage of the response. The client uses this number to detect out of order responses. Each client has a int32 field +which is increased for each message. The sequence id simply wraps around when it overflows. + +The *name* indicates the service method name to invoke. The server uses the same name in the TMessage of the response. + +When the *multiplexed protocol* is used, the name contains the service name, a colon `:` and the method name. The +multiplexed protocol is not compatible with other protocols. + +The *message type* indicates what kind of message is sent. + +Clients send requests with TMessages of type `Call` or `Oneway` (step 1 in the protocol exchange). Servers send +responses with TMessages of type `Exception` or `Reply`. + +### Oneway + +Type
[jira] [Commented] (THRIFT-3867) Specify BinaryProtocol and CompactProtocol
[ https://issues.apache.org/jira/browse/THRIFT-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15357723#comment-15357723 ] ASF GitHub Bot commented on THRIFT-3867: Github user Jens-G commented on a diff in the pull request: https://github.com/apache/thrift/pull/1036#discussion_r69196907 --- Diff: doc/specs/thrift-binary-protocol-encoding.md --- @@ -0,0 +1,467 @@ +Thrift Protocol Encoding for BinaryProtocol and CompactProtocol + + +Last Modified: 2016-Jun-29 + +! WARNING ! + +This document is _work in progress_ and should not (yet) be seen as an authoritative source of information. + +This text is submitted to the Thrift community for review and improvements. + + + +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + + + +There are many ways to encode Thrift on the wire. This documents focuses on the wire encoding for services calls +(encoding and semantics) in the Thrift older *binary protocol* (which has not been documented before) and the +*compact protocol*. Both the regular socket transport (unframed) and the framed transport are described. + +Note that no effort is made to group descriptions of behavior of the Thrift server and the encodings used in the +Thrift wire format. The order in which things are described is such that you can read the document from top to bottom. + +The information here is mostly based on the Java implementation in the Apache thrift library (version 0.9.1) and +[THRIFT-110 A more compact format](https://issues.apache.org/jira/browse/THRIFT-110). Other implementation however, +should behave the same. + +## Message exchange + +Both the binary protocol and the compact protocol assume a transport layer that exposes a bi-directional byte stream, +for example a TCP socket. Both use the following message exchange: + +1. Client sends a `TMessage` (type `Call`). The TMessage contains some metadata and the name of the method to invoke. +2. Client sends method arguments (a struct defined by the generate code). +3. Server sends a `TMessage` (type `Response` or `Exception`) to start the response. +4. Server sends completes response with a struct (a predefined struct or one defined by generated code). + +The pattern is a simple half duplex protocol where the parties alternate in sending a `TMessage` followed by a struct. +What these are is described below. + +Although the standard Apache Thrift Java clients do not support pipelining (sending multiple requests without waiting +for an response), the standard Apache Thrift Java servers do support it. + +## TMessage + +A *TMessage* contains the following information: + +* _Message type_, a message types, one of `Call`, `Reply`, `Exception` and `Oneway`. +* _Sequence id_, an int32 integer. +* _Name_, a string (can be empty). + +The *sequence id* is a simple message id assigned by the client. The server will use the same sequence id in the +TMessage of the response. The client uses this number to detect out of order responses. Each client has a int32 field +which is increased for each message. The sequence id simply wraps around when it overflows. + +The *name* indicates the service method name to invoke. The server uses the same name in the TMessage of the response. + +When the *multiplexed protocol* is used, the name contains the service name, a colon `:` and the method name. The +multiplexed protocol is not compatible with other protocols. + +The *message type* indicates what kind of message is sent. + +Clients send requests with TMessages of type `Call` or `Oneway` (step 1 in the protocol exchange). Servers send +responses with TMessages of type `Exception` or `Reply`. + +### Oneway + +Type
[GitHub] thrift pull request #1036: THRIFT-3867 Specify BinaryProtocol and CompactPro...
Github user Jens-G commented on a diff in the pull request: https://github.com/apache/thrift/pull/1036#discussion_r69196978 --- Diff: doc/specs/thrift-binary-protocol-encoding.md --- @@ -0,0 +1,467 @@ +Thrift Protocol Encoding for BinaryProtocol and CompactProtocol + + +Last Modified: 2016-Jun-29 + +! WARNING ! + +This document is _work in progress_ and should not (yet) be seen as an authoritative source of information. + +This text is submitted to the Thrift community for review and improvements. + + + +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + + + +There are many ways to encode Thrift on the wire. This documents focuses on the wire encoding for services calls +(encoding and semantics) in the Thrift older *binary protocol* (which has not been documented before) and the +*compact protocol*. Both the regular socket transport (unframed) and the framed transport are described. + +Note that no effort is made to group descriptions of behavior of the Thrift server and the encodings used in the +Thrift wire format. The order in which things are described is such that you can read the document from top to bottom. + +The information here is mostly based on the Java implementation in the Apache thrift library (version 0.9.1) and +[THRIFT-110 A more compact format](https://issues.apache.org/jira/browse/THRIFT-110). Other implementation however, +should behave the same. + +## Message exchange + +Both the binary protocol and the compact protocol assume a transport layer that exposes a bi-directional byte stream, +for example a TCP socket. Both use the following message exchange: + +1. Client sends a `TMessage` (type `Call`). The TMessage contains some metadata and the name of the method to invoke. +2. Client sends method arguments (a struct defined by the generate code). +3. Server sends a `TMessage` (type `Response` or `Exception`) to start the response. +4. Server sends completes response with a struct (a predefined struct or one defined by generated code). + +The pattern is a simple half duplex protocol where the parties alternate in sending a `TMessage` followed by a struct. +What these are is described below. + +Although the standard Apache Thrift Java clients do not support pipelining (sending multiple requests without waiting +for an response), the standard Apache Thrift Java servers do support it. + +## TMessage + +A *TMessage* contains the following information: + +* _Message type_, a message types, one of `Call`, `Reply`, `Exception` and `Oneway`. +* _Sequence id_, an int32 integer. +* _Name_, a string (can be empty). + +The *sequence id* is a simple message id assigned by the client. The server will use the same sequence id in the +TMessage of the response. The client uses this number to detect out of order responses. Each client has a int32 field +which is increased for each message. The sequence id simply wraps around when it overflows. + +The *name* indicates the service method name to invoke. The server uses the same name in the TMessage of the response. + +When the *multiplexed protocol* is used, the name contains the service name, a colon `:` and the method name. The +multiplexed protocol is not compatible with other protocols. + +The *message type* indicates what kind of message is sent. + +Clients send requests with TMessages of type `Call` or `Oneway` (step 1 in the protocol exchange). Servers send +responses with TMessages of type `Exception` or `Reply`. + +### Oneway + +Type `Oneway` is only used starting from Apache Thrift 0.9.3. Earlier versions do _not_ send TMessages of type `Oneway`, +even for service methods defined with the `oneway` modifier. + +When client sends a request with type `Oneway`, the
[GitHub] thrift pull request #1036: THRIFT-3867 Specify BinaryProtocol and CompactPro...
Github user Jens-G commented on a diff in the pull request: https://github.com/apache/thrift/pull/1036#discussion_r69196907 --- Diff: doc/specs/thrift-binary-protocol-encoding.md --- @@ -0,0 +1,467 @@ +Thrift Protocol Encoding for BinaryProtocol and CompactProtocol + + +Last Modified: 2016-Jun-29 + +! WARNING ! + +This document is _work in progress_ and should not (yet) be seen as an authoritative source of information. + +This text is submitted to the Thrift community for review and improvements. + + + +Licensed to the Apache Software Foundation (ASF) under one +or more contributor license agreements. See the NOTICE file +distributed with this work for additional information +regarding copyright ownership. The ASF licenses this file +to you under the Apache License, Version 2.0 (the +"License"); you may not use this file except in compliance +with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + +Unless required by applicable law or agreed to in writing, +software distributed under the License is distributed on an +"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +KIND, either express or implied. See the License for the +specific language governing permissions and limitations +under the License. + + + +There are many ways to encode Thrift on the wire. This documents focuses on the wire encoding for services calls +(encoding and semantics) in the Thrift older *binary protocol* (which has not been documented before) and the +*compact protocol*. Both the regular socket transport (unframed) and the framed transport are described. + +Note that no effort is made to group descriptions of behavior of the Thrift server and the encodings used in the +Thrift wire format. The order in which things are described is such that you can read the document from top to bottom. + +The information here is mostly based on the Java implementation in the Apache thrift library (version 0.9.1) and +[THRIFT-110 A more compact format](https://issues.apache.org/jira/browse/THRIFT-110). Other implementation however, +should behave the same. + +## Message exchange + +Both the binary protocol and the compact protocol assume a transport layer that exposes a bi-directional byte stream, +for example a TCP socket. Both use the following message exchange: + +1. Client sends a `TMessage` (type `Call`). The TMessage contains some metadata and the name of the method to invoke. +2. Client sends method arguments (a struct defined by the generate code). +3. Server sends a `TMessage` (type `Response` or `Exception`) to start the response. +4. Server sends completes response with a struct (a predefined struct or one defined by generated code). + +The pattern is a simple half duplex protocol where the parties alternate in sending a `TMessage` followed by a struct. +What these are is described below. + +Although the standard Apache Thrift Java clients do not support pipelining (sending multiple requests without waiting +for an response), the standard Apache Thrift Java servers do support it. + +## TMessage + +A *TMessage* contains the following information: + +* _Message type_, a message types, one of `Call`, `Reply`, `Exception` and `Oneway`. +* _Sequence id_, an int32 integer. +* _Name_, a string (can be empty). + +The *sequence id* is a simple message id assigned by the client. The server will use the same sequence id in the +TMessage of the response. The client uses this number to detect out of order responses. Each client has a int32 field +which is increased for each message. The sequence id simply wraps around when it overflows. + +The *name* indicates the service method name to invoke. The server uses the same name in the TMessage of the response. + +When the *multiplexed protocol* is used, the name contains the service name, a colon `:` and the method name. The +multiplexed protocol is not compatible with other protocols. + +The *message type* indicates what kind of message is sent. + +Clients send requests with TMessages of type `Call` or `Oneway` (step 1 in the protocol exchange). Servers send +responses with TMessages of type `Exception` or `Reply`. + +### Oneway + +Type `Oneway` is only used starting from Apache Thrift 0.9.3. Earlier versions do _not_ send TMessages of type `Oneway`, +even for service methods defined with the `oneway` modifier. + +When client sends a request with type `Oneway`, the
[GitHub] thrift pull request #1037: nodejs client fails to import 'assert'
GitHub user edenhochbaum opened a pull request: https://github.com/apache/thrift/pull/1037 nodejs client fails to import 'assert' So when the connection fails, we just get an error about assert not being defined (rather than details of the connection failure.) You can merge this pull request into a Git repository by running: $ git pull https://github.com/edenhochbaum/thrift master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/thrift/pull/1037.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1037 commit 29be8ce89d7354bc68e5674051862cf1417fe011 Author: Eden HochbaumDate: 2016-06-28T20:49:27Z NodeClient.js fails to import 'assert' commit 5e852eda44341b232b4909341efdae8606920e84 Author: Eden Hochbaum Date: 2016-06-28T20:50:09Z NodeClientPromise.js fails to import 'assert' commit e25a29ffd1ac7491a759d68f470ebbb34008de45 Author: Eden Hochbaum Date: 2016-06-30T16:32:29Z server and client have different shebangs PerlServer.pl and PerlClient.pl have different shebang interpreter directives - let's make them both look for the perl interpreter using /usr/bin/env commit 32058d492a282bbf7baac823994229c9a09b66de Author: Eden Hochbaum Date: 2016-06-30T16:44:19Z Update PerlServer.pl --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] thrift pull request #1035: nodejs client fails to import 'assert'
Github user edenhochbaum closed the pull request at: https://github.com/apache/thrift/pull/1035 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---