Re: How to Get the ObjectID?

On Tue, May 26, 2009 at 02:57:21AM -0600, Alex Co wrote:
> Using the standard rmi client (not the custom socket client) and sniffing=
 the messages that arrive/leave RMI Server,
> I see this:=20

[snip]

> 5#(Receive)
> R
>=20
> 6# (Send)
> S
>=20
> 7# (Receive)
> 00000000  50 AC ED 00 05 77 22 A6 05 2A C8 81 78 12 13 9D    P....w"..*..=
x...
> 00000010  E2 22 A5 00 00 01 21 77 ED CA 46 80 01 FF FF FF    ."....!w..F.=
=2E...
> 00000020  FF EF C1 74 D7 7F AC B4 6D                         ...t.=7F..m =
     =20
> 8# (Send)
> 00000000  51 AC ED 00 05 77 0F 01 9D E2 22 A5 00 00 01 21    Q....w....".=
=2E..!
> 00000010  77 ED CA 46 80 29                                  w..F.)      =
   =20
>=20
> On message 1# (received at RMI server) we can see that client is
> starting up the handshake for the stream protocol.
>=20
> On message 2# the RMI server responds telling RMI client that it
> supports the stream protocol but it also sends to the client, the
> client=92s endpoint.
>
> On message 3#, the RMI client responds to the RMI server with its
> fake listening endpoint (just to respect the protocol).

OK.

> But in this message client sends more information that I can=92t
> understand why nor for what aim either.
>=20
> Message 4# seems to be a response from the RMI server to the
> client=92s strange message (strange at least for me).

That is a java.rmi.dgc.DGC.dirty invocation and result-- a "dirty"
call made by the DGC (distributed garbage collection) RMI system
component on the client side to its counterpart on the server side
informing the server that the client holds live references to certain
remote objects.

> Messages 5 and 6: I don=92t understand them.

Those are "Ping" and "PingAck" messages-- the client was testing the
liveness of the connection before sending another invocation over it,
because it hadn't been used recently enough.

> Message 7# is a call method request from the RMI client for a
> specific method
>=20
> Message 8# is the response to the call message. 0x51 means ok.
>=20
> So, if RMI server shows this:
>=20
> HelloWorldServer[UnicastServerRef [liveRef: [endpoint:[192.168.1.2:27000]=
(local)
> ,objID:[-621ddd5b:12177edca46:-7fff, -6483729047876005357]]]]
>=20
> Why message 7# sends an object id that is different from the one
> showed by the rmi server?
> According to the JDK source code (JDK), an ObjID is sent by the wire
> in this format:
>=20
>          out.writeLong(l); //ObjNum (last field of the RMI server output)
>          out.writeInt();   //First field of the RMI server output (UID:1)
>          out.writeLong();  //Second field of the RMI server output (UID:2)
>          out.writeShort(); //Third field of the RMI server output (UID:3)
>          out.writeInt();   //Method number
>          out.writeLong(l); //method hash
>=20
> Please, could you help me understand these messages and ObjectID
> sent by the client (which is different from the server output)

The ObjID value you provided above:

> HelloWorldServer[UnicastServerRef [liveRef: [endpoint:[192.168.1.2:27000]=
(local)
> ,objID:[-621ddd5b:12177edca46:-7fff, -6483729047876005357]]]]

is indeed encoded like that in message #7:

> 00000000  50 AC ED 00 05 77 22 A6 05 2A C8 81 78 12 13 9D    P....w"..*..=
x...
> 00000010  E2 22 A5 00 00 01 21 77 ED CA 46 80 01 FF FF FF    ."....!w..F.=
=2E...
> 00000020  FF EF C1 74 D7 7F AC B4 6D                         ...t.=7F..m =
    =20

Here are the bytes broken down:

> 50

Indicates "Call" message.

> AC ED 00 05

Magic number and format version of object serialization stream.

> 77 22

java.io.ObjectStreamConstants.TC_BLOCKDATA indicating that there are
0x22 or 34 non-object bytes following in the stream, which is the
number of remaining bytes in the message, so the remainder of the
message consists of non-object data in the serialization stream.

> A6 05 2A C8 81 78 12 13

That is -6483729047876005357 decimal in "long" or 64-bit 2's
complement form.

> 9D E2 22 A5

That is -621ddd5b hex in "int" or 32-bit 2's complement form.

> 00 00 01 21 77 ED CA 46

12177edca46 hex, padded to 64 bits for "long".

> 80 01

-7fff hex in "short" or 16-bit 2's complement form.

> FF FF FF FF

-1 as an "int", indicating the 1.2 stub protocol.

> EF C1 74 D7 7F AC B4 6D

The method hash, as specified on this page:

    http://java.sun.com/javase/6/docs/platform/rmi/spec/rmi-stubs24.html

And that's the end of the message, I presume because this method has
no arguments.

-- Peter

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff RMI-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

For a list of frequently asked RMI questions please refer to:
http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html

To view past RMI-USERS postings, please see:
http://archives.java.sun.com/archives/rmi-users.html