You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Bryan Pendleton (JIRA)" <de...@db.apache.org> on 2006/01/24 19:02:16 UTC
[jira] Created: (DERBY-864) Network Client should not assume length
of Layer B segment is 32K
Network Client should not assume length of Layer B segment is 32K
-----------------------------------------------------------------
Key: DERBY-864
URL: http://issues.apache.org/jira/browse/DERBY-864
Project: Derby
Type: Improvement
Components: Network Client
Versions: 10.2.0.0
Reporter: Bryan Pendleton
Priority: Minor
The Network Client, when processing a Layer-B Segmented DSS block, currently uses the following code:
[java/client/org/apache/derby/client/net/Reply.java]:
if ((continueHeaderLength & 0x8000) == 0x8000) {
// the last dss header is again continued
continueHeaderLength = 32767;
dssIsContinued_ = true;
} else {
// the last dss header was not contiued so update continue state flag
dssIsContinued_ = false;
}
According to my reading of the DRDA spec, this code is making an assumption which is not truly justified by the DSS protocol, namely that if a segment is continued, then its length must be 32767. In practice, the Network Server does implement such a behavior, but I think it would be safer for the client to not make such an assumption, and rather it should get the *actual* length from the contents of the DSS continuation header.
However, there is a slight complexity here. Prior to the fix for DERBY-125, the Network Server did not set the length value of the DSS Continuation Header. Instead of sending a DSS Continuation Header of 0xFFFF, it sent a value of 0x8000.
Therefore, when changing the client, care must be taken to not break compatibility between a new client and an old server. I can think of two ways to do this:
- if the client sees that the the length is 0, it could treat a length of 0 as meaning a length of 32767, or
- if the client can detect the version of the server, and can see that the server is a version prior to DERBY-125, it could assume that the length is always 32767, as it does now.
See http://wiki.apache.org/db-derby/DssProtocolErrors for more information on DSS continuations, and see DERBY-125 for some other background information on this issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-864) Network Client should not assume
length of Layer B segment is 32K
Posted by "David Van Couvering (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-864?page=comments#action_12363864 ]
David Van Couvering commented on DERBY-864:
-------------------------------------------
Do we have version detection at that level of granularity in the protocol? If so, I recommend we use it, othewise option 1, treating a length of 0, works, as long as that isn't possible in the new versions (does one every actually send a 0-byte message?)
> Network Client should not assume length of Layer B segment is 32K
> -----------------------------------------------------------------
>
> Key: DERBY-864
> URL: http://issues.apache.org/jira/browse/DERBY-864
> Project: Derby
> Type: Improvement
> Components: Network Client
> Versions: 10.2.0.0
> Reporter: Bryan Pendleton
> Priority: Minor
>
> The Network Client, when processing a Layer-B Segmented DSS block, currently uses the following code:
> [java/client/org/apache/derby/client/net/Reply.java]:
> if ((continueHeaderLength & 0x8000) == 0x8000) {
> // the last dss header is again continued
> continueHeaderLength = 32767;
> dssIsContinued_ = true;
> } else {
> // the last dss header was not contiued so update continue state flag
> dssIsContinued_ = false;
> }
> According to my reading of the DRDA spec, this code is making an assumption which is not truly justified by the DSS protocol, namely that if a segment is continued, then its length must be 32767. In practice, the Network Server does implement such a behavior, but I think it would be safer for the client to not make such an assumption, and rather it should get the *actual* length from the contents of the DSS continuation header.
> However, there is a slight complexity here. Prior to the fix for DERBY-125, the Network Server did not set the length value of the DSS Continuation Header. Instead of sending a DSS Continuation Header of 0xFFFF, it sent a value of 0x8000.
> Therefore, when changing the client, care must be taken to not break compatibility between a new client and an old server. I can think of two ways to do this:
> - if the client sees that the the length is 0, it could treat a length of 0 as meaning a length of 32767, or
> - if the client can detect the version of the server, and can see that the server is a version prior to DERBY-125, it could assume that the length is always 32767, as it does now.
> See http://wiki.apache.org/db-derby/DssProtocolErrors for more information on DSS continuations, and see DERBY-125 for some other background information on this issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-864) Network Client should not assume
length of Layer B segment is 32K
Posted by Kathey Marsden <km...@sbcglobal.net>.
Knut Anders Hatlen (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-864?page=comments#action_12363878 ]
>
>Knut Anders Hatlen commented on DERBY-864:
>------------------------------------------
>
>David's question: Do we have version detection at that level of granularity in the protocol?
>
>The client driver has a class ProductLevel with methods
> - boolean greaterThanOrEqualTo(int versionLevel, int releaseLevel, int modificationLevel)
> - boolean lessThan(int versionLevel, int releaseLevel, int modificationLevel)
>which let you detect the version of the server.
>
>In Reply.java, we could have something like this:
>
>if (netAgent_.netConnection_.databaseMetaData_.productLevel_.greaterThanOrEqualTo(10, 2, 0)) {
> // new behaviour
>} else {
> // old behaviour
>}
>
>
>
Ideally there would be a boolean in NetDatabaseMetaData set in
computeFeatureSet_() , so that we keep all the version specific stuff
centralized. See this comment in NetDatabaseMetaData.java
// Set flags describing the level of support for this connection.
// Flags will be set based on manager level and/or specific product
identifiers.
// Support for a specific server version can be set as follows. For
example
// if (productLevel_.greaterThanOrEqualTo(11,1,0))
// supportsTheBestThingEver = true
[jira] Commented: (DERBY-864) Network Client should not assume
length of Layer B segment is 32K
Posted by "Knut Anders Hatlen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-864?page=comments#action_12363878 ]
Knut Anders Hatlen commented on DERBY-864:
------------------------------------------
David's question: Do we have version detection at that level of granularity in the protocol?
The client driver has a class ProductLevel with methods
- boolean greaterThanOrEqualTo(int versionLevel, int releaseLevel, int modificationLevel)
- boolean lessThan(int versionLevel, int releaseLevel, int modificationLevel)
which let you detect the version of the server.
In Reply.java, we could have something like this:
if (netAgent_.netConnection_.databaseMetaData_.productLevel_.greaterThanOrEqualTo(10, 2, 0)) {
// new behaviour
} else {
// old behaviour
}
> Network Client should not assume length of Layer B segment is 32K
> -----------------------------------------------------------------
>
> Key: DERBY-864
> URL: http://issues.apache.org/jira/browse/DERBY-864
> Project: Derby
> Type: Improvement
> Components: Network Client
> Versions: 10.2.0.0
> Reporter: Bryan Pendleton
> Priority: Minor
>
> The Network Client, when processing a Layer-B Segmented DSS block, currently uses the following code:
> [java/client/org/apache/derby/client/net/Reply.java]:
> if ((continueHeaderLength & 0x8000) == 0x8000) {
> // the last dss header is again continued
> continueHeaderLength = 32767;
> dssIsContinued_ = true;
> } else {
> // the last dss header was not contiued so update continue state flag
> dssIsContinued_ = false;
> }
> According to my reading of the DRDA spec, this code is making an assumption which is not truly justified by the DSS protocol, namely that if a segment is continued, then its length must be 32767. In practice, the Network Server does implement such a behavior, but I think it would be safer for the client to not make such an assumption, and rather it should get the *actual* length from the contents of the DSS continuation header.
> However, there is a slight complexity here. Prior to the fix for DERBY-125, the Network Server did not set the length value of the DSS Continuation Header. Instead of sending a DSS Continuation Header of 0xFFFF, it sent a value of 0x8000.
> Therefore, when changing the client, care must be taken to not break compatibility between a new client and an old server. I can think of two ways to do this:
> - if the client sees that the the length is 0, it could treat a length of 0 as meaning a length of 32767, or
> - if the client can detect the version of the server, and can see that the server is a version prior to DERBY-125, it could assume that the length is always 32767, as it does now.
> See http://wiki.apache.org/db-derby/DssProtocolErrors for more information on DSS continuations, and see DERBY-125 for some other background information on this issue.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira