P4
The Java Remote Method Invocation Specification's Chapter 10, "RMI Wire
Protocol", which is really the specification for the JRMP wire protocol,
includes the following deficiencies:
- The "Version" component of the connection header sent by the client is
specified (in section 10.2.1) to be the literal sequence of octets 0x00 0x01.
In reality, however, this sequence has always been 0x00 0x02 since RMI first
became part of Java (in JDK 1.1), so it appears as if the spec is only
specifying an earlier version of the protocol than has always been provided.
The spec should be updated to specify that 0x00 0x02 is the only value of
"Version" supported, because no FCS version of RMI (JRMP) has ever supported
0x00 0x01.
- The "endpoint negotiation" for the StreamProtocol and the MultiplexProtocol is described tangentially and vaguely in this text from section 10.2.1:
For the StreamProtocol and the MultiplexProtocol, the server must respond
with a a [sic] byte 0x4e acknowledging support for the protocol, and an
EndpointIdentifier that contains the host name and port number that the
server can see is being used by the client. The client can use this
information to determine its host name if it is otherwise unable to do that
for security reasons. The client must then respond with another
EndpointIdentifier that contains the client's default endpoint for accepting
connections. This can be used by a server in the MultiplexProtocol case to
identify the client.
For the StreamProtocol, after this endpoint negotiation...
The wire format of these EndointIdentifier entities is not specified (in
reality, the format is the host IP string in DataOutput.writeUTF format followed
by the port number in DataOutput.writeInt format). Also, this piece of the
protocol is not well integrated into the surrounding description, such as in the
grammars for "Out" or "In". In particular, section 10.2.2 "Format of an Input
Stream" makes no mention of it at all (it needs to be implied from 10.2.1), so
an isolated look at that section would seem to indicate that "ProtocolAck"
should always be directly followed by "Returns".
Protocol", which is really the specification for the JRMP wire protocol,
includes the following deficiencies:
- The "Version" component of the connection header sent by the client is
specified (in section 10.2.1) to be the literal sequence of octets 0x00 0x01.
In reality, however, this sequence has always been 0x00 0x02 since RMI first
became part of Java (in JDK 1.1), so it appears as if the spec is only
specifying an earlier version of the protocol than has always been provided.
The spec should be updated to specify that 0x00 0x02 is the only value of
"Version" supported, because no FCS version of RMI (JRMP) has ever supported
0x00 0x01.
- The "endpoint negotiation" for the StreamProtocol and the MultiplexProtocol is described tangentially and vaguely in this text from section 10.2.1:
For the StreamProtocol and the MultiplexProtocol, the server must respond
with a a [sic] byte 0x4e acknowledging support for the protocol, and an
EndpointIdentifier that contains the host name and port number that the
server can see is being used by the client. The client can use this
information to determine its host name if it is otherwise unable to do that
for security reasons. The client must then respond with another
EndpointIdentifier that contains the client's default endpoint for accepting
connections. This can be used by a server in the MultiplexProtocol case to
identify the client.
For the StreamProtocol, after this endpoint negotiation...
The wire format of these EndointIdentifier entities is not specified (in
reality, the format is the host IP string in DataOutput.writeUTF format followed
by the port number in DataOutput.writeInt format). Also, this piece of the
protocol is not well integrated into the surrounding description, such as in the
grammars for "Out" or "In". In particular, section 10.2.2 "Format of an Input
Stream" makes no mention of it at all (it needs to be implied from 10.2.1), so
an isolated look at that section would seem to indicate that "ProtocolAck"
should always be directly followed by "Returns".