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
