You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@river.apache.org by helcio silva <su...@gmail.com> on 2010/03/23 23:14:03 UTC
Help on to decode information encapsulated by TCP segment during JINI
discovery.
Hello, gentlemen. How are you?
Well, I'm interested in to investigate the bandwidth consumed by
JINI applications. In order to do it, I'm using wireshark to capture
some PDUs (Packet Data Units) from wire. So, I've captured the
following application layer PDU:
0000 ac ed 00 05 73 72 00 19 6a 61 76 61 2e 72 6d 69 ....sr..java.rmi
0010 2e 4d 61 72 73 68 61 6c 6c 65 64 4f 62 6a 65 63 .MarshalledObjec
0020 74 7c bd 1e 97 ed 63 fc 3e 02 00 03 49 00 04 68 t|....c.>...I..h
0030 61 73 68 5b 00 08 6c 6f 63 42 79 74 65 73 74 00 ash[..locBytest.
0040 02 5b 42 5b 00 08 6f 62 6a 42 79 74 65 73 71 00 .[B[..objBytesq.
0050 7e 00 01 78 70 43 71 e8 93 75 72 00 02 5b 42 ac ~..xpCq..ur..[B.
0060 f3 17 f8 06 08 54 e0 02 00 00 78 70 00 00 00 58 .....T....xp...X
0070 ac ed 00 05 74 00 4a 68 74 74 70 3a 2f 2f 31 37 ....t.Jhttp://17
0080 32 2e 31 37 2e 33 2e 31 36 32 3a 38 30 38 30 2f 2.17.3.162:8080/
0090 72 65 67 67 69 65 2d 64 6c 2e 6a 61 72 20 68 74 reggie-dl.jar ht
00a0 74 70 3a 2f 2f 31 37 32 2e 31 37 2e 33 2e 31 36 tp://172.17.3.16
00b0 32 3a 38 30 38 30 2f 6a 73 6b 2d 64 6c 2e 6a 61 2:8080/jsk-dl.ja
00c0 72 71 00 7e 00 00 70 70 75 71 00 7e 00 03 00 00 rq.~..ppuq.~....
00d0 01 3a ac ed 00 05 73 72 00 22 63 6f 6d 2e 73 75 .:....sr."com.su
00e0 6e 2e 6a 69 6e 69 2e 72 65 67 67 69 65 2e 52 65 n.jini.reggie.Re
00f0 67 69 73 74 72 61 72 50 72 6f 78 79 00 00 00 00 gistrarProxy....
0100 00 00 00 02 03 00 01 4c 00 06 73 65 72 76 65 72 .......L..server
0110 74 00 1f 4c 63 6f 6d 2f 73 75 6e 2f 6a 69 6e 69 t..Lcom/sun/jini
0120 2f 72 65 67 67 69 65 2f 52 65 67 69 73 74 72 61 /reggie/Registra
0130 72 3b 78 70 73 72 00 26 63 6f 6d 2e 73 75 6e 2e r;xpsr.&com.sun.
0140 6a 69 6e 69 2e 72 65 67 67 69 65 2e 52 65 67 69 jini.reggie.Regi
0150 73 74 72 61 72 49 6d 70 6c 5f 53 74 75 62 00 00 strarImpl_Stub..
0160 00 00 00 00 00 02 02 00 00 78 72 00 1a 6a 61 76 .........xr..jav
0170 61 2e 72 6d 69 2e 73 65 72 76 65 72 2e 52 65 6d a.rmi.server.Rem
0180 6f 74 65 53 74 75 62 e9 fe dc c9 8b e1 65 1a 02 oteStub......e..
0190 00 00 78 72 00 1c 6a 61 76 61 2e 72 6d 69 2e 73 ..xr..java.rmi.s
01a0 65 72 76 65 72 2e 52 65 6d 6f 74 65 4f 62 6a 65 erver.RemoteObje
01b0 63 74 d3 61 b4 91 0c 61 33 1e 03 00 00 78 70 77 ct.a...a3....xpw
01c0 37 00 0b 55 6e 69 63 61 73 74 52 65 66 32 00 00 7..UnicastRef2..
01d0 0c 31 37 32 2e 31 37 2e 33 2e 31 36 32 00 00 af .172.17.3.162...
01e0 a3 b6 8b af e2 22 c4 2b 9f b0 19 e3 dd 00 00 01 .....".+........
01f0 28 2b f3 bb c1 80 01 00 78 77 10 20 f5 a8 9b 3f (+......xw. ...?
0200 64 46 93 b5 69 33 f9 5f 39 37 24 78 77 0c 00 00 dF..i3._97$xw...
0210 00 01 00 06 70 75 62 6c 69 63 ....public
The printable characters give some glue about what is going on. As
a matter of fact, the PDU above is sent by reggie to a client to
provide information related where that client can download a proxy to
it (reggie). In the JINI specification we can find the format for
discovery requests sent by clients, as well the announces performed by
Lookup Services. But I can't find a precise definition for this kind
of PDU above. Does somebody can help me?
Thanks in advance, gentlemen!!!
Helcio.
Re: Help on to decode information encapsulated by TCP segment during JINI discovery.
Posted by Dennis Reedy <de...@gmail.com>.
On Mar 27, 2010, at 1024PM, Shay Hassidim wrote:
>
>
> Contributing the specific code we have created to enhance the Jini
> components would involve submitting also our proprietary communication
> protocol technology and other components that provide us uniqueness when
> competing with other products on the market. When having such a
> competitive environment in a very hot market, I'm not sure it makes
> sense to do so.
You are right, providing the source for your proprietary communication protocol does not make sense.
But I am confused as to how your wire protocol and reggie internals intersect. Your wire protocol is how clients talk to the space, not how reggie scales right? I should be able to use your modified reggie by using 'stock' River components right? Or are you locked into using the GigaSpaces platform?
Perhaps you could summarize the issue(s) you addressed with reggie internals? Would that work for you?
Re: Help on to decode information encapsulated by TCP segment during JINI discovery.
Posted by Dennis Reedy <de...@gmail.com>.
Shay,
IMO, if you have benefited from the code, and improved it, give it back to the community from which it came from. Of course you are not required to do so, but it would make your efforts more approachable.
Regards
Dennis
On Mar 27, 2010, at 1024PM, Shay Hassidim wrote:
> Dennis,
>
>
>
> Our contribution to the community includes vast amount of activities. I
> will list few of them:
>
> - A community edition product - free of charge to be used in development
> and production. This is the full product that allows users to enjoy our
> enhanced lookup service, transaction manager and a world class
> industrial JavaSpace implementation. This edition allows users to have
> unlimited amount of clients, deploying unlimited amount of POJO/Jini
> services and also have unlimited of local cache nodes. It does limit the
> amount of the JavaSpace nodes to one (i.e. non-clustered).
>
> - A start-up program - provides the above without any limitation on the
> JavaSpace cluster size for start-up companies free of charge. It allows
> users also to enjoy the other API's we provide such as JCache, JMS, JDBC
> API and also our C++ and .Net JavaSpace API libraries. I must admit the
> .Net JavaSpace has a huge success.
>
> - 100% of the client code is open source - It is provided as part of the
> product distribution. This includes top quality documentation and allows
> users to learn our client internals and debug it in case of problems.
> Users also often use this code to enhance our built-in capabilities to
> be customized for their specific needs.
>
> - Public forum - Allows users to submit questions and get answers
> directly from engineering and our architects around the world free of
> charge.
>
> - Promoting other open source products we use - these includes Spring ,
> Jetty , Hibernate , Maven , your Rio project and others.
>
> - www.openspaces.org <http://www.openspaces.org/> - a site that allows
> users to host their open source projects. The projects build around our
> JavaSpace implementation.
>
>
>
> See more details here: http://www.gigaspaces.com/communitycontribution
>
>
>
> As you can see, there are very few companies around the world that
> promotes Jini/JavaSpaces as GigaSpaces.
>
>
>
> Contributing the specific code we have created to enhance the Jini
> components would involve submitting also our proprietary communication
> protocol technology and other components that provide us uniqueness when
> competing with other products on the market. When having such a
> competitive environment in a very hot market, I'm not sure it makes
> sense to do so.
>
>
>
> Shay
>
> -----Original Message-----
> From: Dennis Reedy [mailto:dennis.reedy@gmail.com]
> Sent: Saturday, March 27, 2010 8:19 PM
> To: river-user@incubator.apache.org
> Subject: Re: Help on to decode information encapsulated by TCP segment
> during JINI discovery.
>
>
>
> Hey Shay,
>
>
>
> Why dont you just contribute them to the community? Or do you want to
> continue to just take from open source and not give back?
>
>
>
> Dennis
>
>
>
> On Mar 27, 2010, at 725PM, Shay Hassidim wrote:
>
>
>
>> What a great write up Jim.
>
>>
>
>> GigaSpaces has improved some of the reggie internals to be more
> scalable
>
>> and faster.
>
>>
>
>> If you are looking for more info about these enhancements please
> contact
>
>> me directly.
>
>>
>
>> Best Regards,
>
>>
>
>> ----------------------------------------------------
>
>> Shay Hassidim
>
>> Deputy CTO
>
>> GigaSpaces Technologies
>
>
>
RE: Help on to decode information encapsulated by TCP segment during JINI discovery.
Posted by Shay Hassidim <sh...@gigaspaces.com>.
Dennis,
Our contribution to the community includes vast amount of activities. I
will list few of them:
- A community edition product - free of charge to be used in development
and production. This is the full product that allows users to enjoy our
enhanced lookup service, transaction manager and a world class
industrial JavaSpace implementation. This edition allows users to have
unlimited amount of clients, deploying unlimited amount of POJO/Jini
services and also have unlimited of local cache nodes. It does limit the
amount of the JavaSpace nodes to one (i.e. non-clustered).
- A start-up program - provides the above without any limitation on the
JavaSpace cluster size for start-up companies free of charge. It allows
users also to enjoy the other API's we provide such as JCache, JMS, JDBC
API and also our C++ and .Net JavaSpace API libraries. I must admit the
.Net JavaSpace has a huge success.
- 100% of the client code is open source - It is provided as part of the
product distribution. This includes top quality documentation and allows
users to learn our client internals and debug it in case of problems.
Users also often use this code to enhance our built-in capabilities to
be customized for their specific needs.
- Public forum - Allows users to submit questions and get answers
directly from engineering and our architects around the world free of
charge.
- Promoting other open source products we use - these includes Spring ,
Jetty , Hibernate , Maven , your Rio project and others.
- www.openspaces.org <http://www.openspaces.org/> - a site that allows
users to host their open source projects. The projects build around our
JavaSpace implementation.
See more details here: http://www.gigaspaces.com/communitycontribution
As you can see, there are very few companies around the world that
promotes Jini/JavaSpaces as GigaSpaces.
Contributing the specific code we have created to enhance the Jini
components would involve submitting also our proprietary communication
protocol technology and other components that provide us uniqueness when
competing with other products on the market. When having such a
competitive environment in a very hot market, I'm not sure it makes
sense to do so.
Shay
-----Original Message-----
From: Dennis Reedy [mailto:dennis.reedy@gmail.com]
Sent: Saturday, March 27, 2010 8:19 PM
To: river-user@incubator.apache.org
Subject: Re: Help on to decode information encapsulated by TCP segment
during JINI discovery.
Hey Shay,
Why dont you just contribute them to the community? Or do you want to
continue to just take from open source and not give back?
Dennis
On Mar 27, 2010, at 725PM, Shay Hassidim wrote:
> What a great write up Jim.
>
> GigaSpaces has improved some of the reggie internals to be more
scalable
> and faster.
>
> If you are looking for more info about these enhancements please
contact
> me directly.
>
> Best Regards,
>
> ----------------------------------------------------
> Shay Hassidim
> Deputy CTO
> GigaSpaces Technologies
Re: Help on to decode information encapsulated by TCP segment during JINI discovery.
Posted by Dennis Reedy <de...@gmail.com>.
Hey Shay,
Why dont you just contribute them to the community? Or do you want to continue to just take from open source and not give back?
Dennis
On Mar 27, 2010, at 725PM, Shay Hassidim wrote:
> What a great write up Jim.
>
> GigaSpaces has improved some of the reggie internals to be more scalable
> and faster.
>
> If you are looking for more info about these enhancements please contact
> me directly.
>
> Best Regards,
>
> ----------------------------------------------------
> Shay Hassidim
> Deputy CTO
> GigaSpaces Technologies
>
>
>
> -----Original Message-----
> From: Jim.Waldo@Sun.COM [mailto:Jim.Waldo@Sun.COM]
> Sent: Saturday, March 27, 2010 11:06 AM
> To: river-user@incubator.apache.org
> Subject: Re: Help on to decode information encapsulated by TCP segment
> during JINI discovery.
>
>
>
> Well, as they say in the auto ads, your mileage may vary...
>
>
>
> The best place to see how much bandwidth is being used by the river
> implementations is to take a look at the source code. But even there it
> is going to depend on how often you have services or clients of services
> joining the network (since they have to do a multicast to find the
> lookup services) and how you configure your lease renewal periods. The
> shorter the lease period, the more bandwidth will be used by renewals
> but the more accurate your snapshot of the network; longer renewal
> periods mean less traffic but a longer period during which a service may
> be unavailable but still registered. It will also depend on how the
> services choose to split the work between the service proxy and the
> service itself-- if you, for example, decide to cache information in a
> service proxy you can lower the bandwidth used by the service (although
> you increase the memory needed by the proxy).
>
>
>
> But the experience of most who deployed Jini systems was that the vast
> majority of the network bandwidth was taken up with service-to-service
> communication (or client to service) rather than with the infrastructure
> communication. Which is not surprising. Asking how much bandwidth Jini
> takes up is sort of like asking how fast an operating system runs--
> while there are ways of measuring, in fact most of the time will be
> taken up by the applications, not the infrastructure.
>
>
>
> Jim
>
>
>
> On Mar 26, 2010, at 4:01 PM, helcio silva wrote:
>
>
>
>> Hi, Jim. I'm very happy to be talking to you, one of most important
>
>> participants on design of JINI architecture.
>
>>
>
>> In fact, remembering of the concepts behind JINI, it makes all
>
>> sense the JINI protocols specification does not to contain the meaning
>
>> of that PDU shown. It is related to the reference implementation of
>
>> LUS (reggie), not to the standard itself.
>
>>
>
>> Currently, I am working on evaluating JINI taking in account the
>
>> bandwidth comsuption. Thus, I need to know exactly what is going on
>
>> the wire. I can see now that those PDUs are related to the reference
>
>> implementation, not to standard itself, but I still want to know what
>
>> they mean.
>
>>
>
>> Please, Jim, can you point to me where can I find some information
>
>> about the protocol developed for the LUS reference implementation?
>
>>
>
>> Kindest regards to all, gentlemen.
>
>>
>
>> Helcio.
>
>>
>
>> 2010/3/26 Jim Waldo <Ji...@sun.com>:
>
>>> Well, the reason that this information is not in the Jini
> specification is that it is an artifact of the particular Jini
> implementation, not something that defines the Jini system.
>
>>>
>
>>> What the specification says is that the lookup service will return a
> proxy to that service as part of discovery. That proxy will implement a
> particular Java interface, and will allow communication with the lookup
> service from the client. But the specification does not say how that
> communication is done; that is a private matter between the lookup
> service and the proxy handed out by the lookup service.
>
>>>
>
>>> By looking at the particular implementation, you have been able to
> find out a lot about how that communication is done in this pair of
> service and proxy. But there could be a Jini lookup service that did the
> communication an entirely different way (say, handed back a proxy that
> contained all of the contents of the lookup service, that was informed
> about changes but dealt with all requests from a client locally to that
> client) and that would be a fine implementation of the service. As long
> as it follows the spec, how it does so is up to the implementation (and
> the implementor).
>
>>>
>
>>> One of the points of the original Jini design was to make the wire
> protocol part of the implementation rather than part of the
> specification. And that's why what you have been seeing is not in the
> spec...
>
>>>
>
>>> Jim Waldo
>
>>>
>
>>> Note that this mail address will disappear sometime in the near
> future. Please update your address book with my new address,
> jim.waldo@oracle.com
>
>>>
>
>>> On Mar 26, 2010, at 1:32 PM, helcio silva wrote:
>
>>>
>
>>>> Hi, gentlemen.
>
>>>>
>
>>>> I am very happy with all this conversation. In fact, there are
> some
>
>>>> "black holes" in JINI specification. This is only my opinion, and I
> do
>
>>>> not put it as an universal truth...
>
>>>>
>
>>>> Regarding the PDU itself, I will try to decode it using the RMI
>
>>>> specification. Thanks all by clarifications.
>
>>>>
>
>>>> I would like to expose some facts about that PDU and others. Those
>
>>>> facts are result of observations performed by me when using
> wireshark
>
>>>> to capture packets from wire.
>
>>>>
>
>>>> First of all, when a LUS receives a MRP request sent by a client,
>
>>>> that LUS opens a TCP connection with that client. The TCP port used
> by
>
>>>> client is that present on MRP request, as it can be seen on the MRP
>
>>>> specification.
>
>>>>
>
>>>> After establishment of that TCP connection, two PDU are exchanged.
>
>>>> Initially, the client sends a PDU composed by 4 Bytes (in my
> captures,
>
>>>> those 4 Bytes are 00 00 00 01). I don't know EXACTLY what they mean
>
>>>> (would be a version number?) So, the LUS sends the PDU posted by me
>
>>>> in the first email. Similarly, I don't know EXACTLY what it means.
>
>>>> Although I have an idea, I don't know what mean all its fields. The
>
>>>> TCP connection is then finished.
>
>>>>
>
>>>> After that, a new connection is opened between the client and the
>
>>>> Web server responsible by reggie-dl.jar and jsk-dl.jar files. The
>
>>>> client sends an HTTP request, using the HEAD method and directed to
>
>>>> reggie-dl.jar file. Then, It receives an HTTP response and the TCP
>
>>>> connection is closed.
>
>>>>
>
>>>> Another TCP connection is established between the client and the
>
>>>> Web server. A new HTTP request is sent by client, using the GET
> method
>
>>>> and directed to reggie-dl.jar file. That file is downloaded by
> client.
>
>>>> An interesting fact, gentlemen: the reggie-dl.jar file has 58060 B,
>
>>>> and the MSS (Maximum Segment Size) for a machine beloging to an
>
>>>> Ethernet segment is 1448 B. Therefore, there is need for 41 HTTP
>
>>>> response PDUs to transport that file from Web server to client.
> After
>
>>>> download is complete, the TCP connection is closed.
>
>>>>
>
>>>> Finally, a new TCP connection is established between the same
>
>>>> components. This time, however, the client sends an HTTP request to
>
>>>> download the jsk-dl.jar file. Similarly, there is need for more than
>
>>>> one HTTP PDU to do it. More specifically, the jsk-dl.jar file has
>
>>>> 63997 B. Using 1448 B as MSS, we can see (I saw, believe!) that
> there
>
>>>> are need for 45 HTTP response PDUs to download that file.
>
>>>>
>
>>>> When watching the JINI protocols specification, I didn't find any
>
>>>> information about I exposed above.
>
>>>>
>
>>>> Thanks again, gentlemen.
>
>>>>
>
>>>> Helcio.
>
>>>>
>
>>>> 2010/3/26 Alfredo Ramos <al...@rayamos.com>:
>
>>>>> On 26 March 2010 09:35, Sim IJskes - QCG <si...@qcg.nl> wrote:
>
>>>>>
>
>>>>>> helcio silva wrote:
>
>>>>>>
>
>>>>>>> Second. I think the trace posted does not contain any
> serialized
>
>>>>>>> class. As can be seen, there is much ascii codified text. For
> example,
>
>>>>>>>
>
>>>>>>
>
>>>>>> Are you really, really sure?
>
>>>>>>
>
>>>>>>
>
>>>>> Don't be mean, just tell him...
>
>>>>>
>
>>>>> That is a Serialized MarshalledObject that contains a remote
> reference to
>
>>>>> the Registrar server hosted by the Lookup Discovery Service (i.e.
> reggie).
>
>>>>> The http URLs you see as part of the packet are class annotations.
>
>>>>>
>
>>>>> It is in reality RMI serialization, JINI services are RMI servers,
> see
>
>>>>>
> http://java.sun.com/j2se/1.4.2/docs/guide/rmi/spec/rmi-protocol4.html
>
>>>>>
>
>>>>> This package is normally a multicast response to a multicast
> request, but
>
>>>>> could be also a response to a unicast discovery request (as it is
> used in
>
>>>>> both cases).
>
>>>>>
>
>>>>> See more details at:
>
>>>>>
> http://www.jini.org/wiki/Jini_Discovery_and_Join_Specification#The_Disco
> very_Protocols
>
>>>>>
>
>>>>> This package is the bit that reads:
>
>>>>> "A multicast response client responds to callers, passing each a
> proxy that
>
>>>>> allows it to communicate with its lookup service."
>
>>>>>
>
>>>>> Have fun,
>
>>>>>
>
>>>>> Alfredo Ramos
>
>>>>>
>
>>>
>
>>>
>
>
>
RE: Help on to decode information encapsulated by TCP segment during JINI discovery.
Posted by Shay Hassidim <sh...@gigaspaces.com>.
What a great write up Jim.
GigaSpaces has improved some of the reggie internals to be more scalable
and faster.
If you are looking for more info about these enhancements please contact
me directly.
Best Regards,
----------------------------------------------------
Shay Hassidim
Deputy CTO
GigaSpaces Technologies
-----Original Message-----
From: Jim.Waldo@Sun.COM [mailto:Jim.Waldo@Sun.COM]
Sent: Saturday, March 27, 2010 11:06 AM
To: river-user@incubator.apache.org
Subject: Re: Help on to decode information encapsulated by TCP segment
during JINI discovery.
Well, as they say in the auto ads, your mileage may vary...
The best place to see how much bandwidth is being used by the river
implementations is to take a look at the source code. But even there it
is going to depend on how often you have services or clients of services
joining the network (since they have to do a multicast to find the
lookup services) and how you configure your lease renewal periods. The
shorter the lease period, the more bandwidth will be used by renewals
but the more accurate your snapshot of the network; longer renewal
periods mean less traffic but a longer period during which a service may
be unavailable but still registered. It will also depend on how the
services choose to split the work between the service proxy and the
service itself-- if you, for example, decide to cache information in a
service proxy you can lower the bandwidth used by the service (although
you increase the memory needed by the proxy).
But the experience of most who deployed Jini systems was that the vast
majority of the network bandwidth was taken up with service-to-service
communication (or client to service) rather than with the infrastructure
communication. Which is not surprising. Asking how much bandwidth Jini
takes up is sort of like asking how fast an operating system runs--
while there are ways of measuring, in fact most of the time will be
taken up by the applications, not the infrastructure.
Jim
On Mar 26, 2010, at 4:01 PM, helcio silva wrote:
> Hi, Jim. I'm very happy to be talking to you, one of most important
> participants on design of JINI architecture.
>
> In fact, remembering of the concepts behind JINI, it makes all
> sense the JINI protocols specification does not to contain the meaning
> of that PDU shown. It is related to the reference implementation of
> LUS (reggie), not to the standard itself.
>
> Currently, I am working on evaluating JINI taking in account the
> bandwidth comsuption. Thus, I need to know exactly what is going on
> the wire. I can see now that those PDUs are related to the reference
> implementation, not to standard itself, but I still want to know what
> they mean.
>
> Please, Jim, can you point to me where can I find some information
> about the protocol developed for the LUS reference implementation?
>
> Kindest regards to all, gentlemen.
>
> Helcio.
>
> 2010/3/26 Jim Waldo <Ji...@sun.com>:
>> Well, the reason that this information is not in the Jini
specification is that it is an artifact of the particular Jini
implementation, not something that defines the Jini system.
>>
>> What the specification says is that the lookup service will return a
proxy to that service as part of discovery. That proxy will implement a
particular Java interface, and will allow communication with the lookup
service from the client. But the specification does not say how that
communication is done; that is a private matter between the lookup
service and the proxy handed out by the lookup service.
>>
>> By looking at the particular implementation, you have been able to
find out a lot about how that communication is done in this pair of
service and proxy. But there could be a Jini lookup service that did the
communication an entirely different way (say, handed back a proxy that
contained all of the contents of the lookup service, that was informed
about changes but dealt with all requests from a client locally to that
client) and that would be a fine implementation of the service. As long
as it follows the spec, how it does so is up to the implementation (and
the implementor).
>>
>> One of the points of the original Jini design was to make the wire
protocol part of the implementation rather than part of the
specification. And that's why what you have been seeing is not in the
spec...
>>
>> Jim Waldo
>>
>> Note that this mail address will disappear sometime in the near
future. Please update your address book with my new address,
jim.waldo@oracle.com
>>
>> On Mar 26, 2010, at 1:32 PM, helcio silva wrote:
>>
>>> Hi, gentlemen.
>>>
>>> I am very happy with all this conversation. In fact, there are
some
>>> "black holes" in JINI specification. This is only my opinion, and I
do
>>> not put it as an universal truth...
>>>
>>> Regarding the PDU itself, I will try to decode it using the RMI
>>> specification. Thanks all by clarifications.
>>>
>>> I would like to expose some facts about that PDU and others. Those
>>> facts are result of observations performed by me when using
wireshark
>>> to capture packets from wire.
>>>
>>> First of all, when a LUS receives a MRP request sent by a client,
>>> that LUS opens a TCP connection with that client. The TCP port used
by
>>> client is that present on MRP request, as it can be seen on the MRP
>>> specification.
>>>
>>> After establishment of that TCP connection, two PDU are exchanged.
>>> Initially, the client sends a PDU composed by 4 Bytes (in my
captures,
>>> those 4 Bytes are 00 00 00 01). I don't know EXACTLY what they mean
>>> (would be a version number?) So, the LUS sends the PDU posted by me
>>> in the first email. Similarly, I don't know EXACTLY what it means.
>>> Although I have an idea, I don't know what mean all its fields. The
>>> TCP connection is then finished.
>>>
>>> After that, a new connection is opened between the client and the
>>> Web server responsible by reggie-dl.jar and jsk-dl.jar files. The
>>> client sends an HTTP request, using the HEAD method and directed to
>>> reggie-dl.jar file. Then, It receives an HTTP response and the TCP
>>> connection is closed.
>>>
>>> Another TCP connection is established between the client and the
>>> Web server. A new HTTP request is sent by client, using the GET
method
>>> and directed to reggie-dl.jar file. That file is downloaded by
client.
>>> An interesting fact, gentlemen: the reggie-dl.jar file has 58060 B,
>>> and the MSS (Maximum Segment Size) for a machine beloging to an
>>> Ethernet segment is 1448 B. Therefore, there is need for 41 HTTP
>>> response PDUs to transport that file from Web server to client.
After
>>> download is complete, the TCP connection is closed.
>>>
>>> Finally, a new TCP connection is established between the same
>>> components. This time, however, the client sends an HTTP request to
>>> download the jsk-dl.jar file. Similarly, there is need for more than
>>> one HTTP PDU to do it. More specifically, the jsk-dl.jar file has
>>> 63997 B. Using 1448 B as MSS, we can see (I saw, believe!) that
there
>>> are need for 45 HTTP response PDUs to download that file.
>>>
>>> When watching the JINI protocols specification, I didn't find any
>>> information about I exposed above.
>>>
>>> Thanks again, gentlemen.
>>>
>>> Helcio.
>>>
>>> 2010/3/26 Alfredo Ramos <al...@rayamos.com>:
>>>> On 26 March 2010 09:35, Sim IJskes - QCG <si...@qcg.nl> wrote:
>>>>
>>>>> helcio silva wrote:
>>>>>
>>>>>> Second. I think the trace posted does not contain any
serialized
>>>>>> class. As can be seen, there is much ascii codified text. For
example,
>>>>>>
>>>>>
>>>>> Are you really, really sure?
>>>>>
>>>>>
>>>> Don't be mean, just tell him...
>>>>
>>>> That is a Serialized MarshalledObject that contains a remote
reference to
>>>> the Registrar server hosted by the Lookup Discovery Service (i.e.
reggie).
>>>> The http URLs you see as part of the packet are class annotations.
>>>>
>>>> It is in reality RMI serialization, JINI services are RMI servers,
see
>>>>
http://java.sun.com/j2se/1.4.2/docs/guide/rmi/spec/rmi-protocol4.html
>>>>
>>>> This package is normally a multicast response to a multicast
request, but
>>>> could be also a response to a unicast discovery request (as it is
used in
>>>> both cases).
>>>>
>>>> See more details at:
>>>>
http://www.jini.org/wiki/Jini_Discovery_and_Join_Specification#The_Disco
very_Protocols
>>>>
>>>> This package is the bit that reads:
>>>> "A multicast response client responds to callers, passing each a
proxy that
>>>> allows it to communicate with its lookup service."
>>>>
>>>> Have fun,
>>>>
>>>> Alfredo Ramos
>>>>
>>
>>
Re: Help on to decode information encapsulated by TCP segment during
JINI discovery.
Posted by Jim Waldo <Ji...@Sun.COM>.
Well, as they say in the auto ads, your mileage may vary...
The best place to see how much bandwidth is being used by the river implementations is to take a look at the source code. But even there it is going to depend on how often you have services or clients of services joining the network (since they have to do a multicast to find the lookup services) and how you configure your lease renewal periods. The shorter the lease period, the more bandwidth will be used by renewals but the more accurate your snapshot of the network; longer renewal periods mean less traffic but a longer period during which a service may be unavailable but still registered. It will also depend on how the services choose to split the work between the service proxy and the service itself-- if you, for example, decide to cache information in a service proxy you can lower the bandwidth used by the service (although you increase the memory needed by the proxy).
But the experience of most who deployed Jini systems was that the vast majority of the network bandwidth was taken up with service-to-service communication (or client to service) rather than with the infrastructure communication. Which is not surprising. Asking how much bandwidth Jini takes up is sort of like asking how fast an operating system runs-- while there are ways of measuring, in fact most of the time will be taken up by the applications, not the infrastructure.
Jim
On Mar 26, 2010, at 4:01 PM, helcio silva wrote:
> Hi, Jim. I'm very happy to be talking to you, one of most important
> participants on design of JINI architecture.
>
> In fact, remembering of the concepts behind JINI, it makes all
> sense the JINI protocols specification does not to contain the meaning
> of that PDU shown. It is related to the reference implementation of
> LUS (reggie), not to the standard itself.
>
> Currently, I am working on evaluating JINI taking in account the
> bandwidth comsuption. Thus, I need to know exactly what is going on
> the wire. I can see now that those PDUs are related to the reference
> implementation, not to standard itself, but I still want to know what
> they mean.
>
> Please, Jim, can you point to me where can I find some information
> about the protocol developed for the LUS reference implementation?
>
> Kindest regards to all, gentlemen.
>
> Helcio.
>
> 2010/3/26 Jim Waldo <Ji...@sun.com>:
>> Well, the reason that this information is not in the Jini specification is that it is an artifact of the particular Jini implementation, not something that defines the Jini system.
>>
>> What the specification says is that the lookup service will return a proxy to that service as part of discovery. That proxy will implement a particular Java interface, and will allow communication with the lookup service from the client. But the specification does not say how that communication is done; that is a private matter between the lookup service and the proxy handed out by the lookup service.
>>
>> By looking at the particular implementation, you have been able to find out a lot about how that communication is done in this pair of service and proxy. But there could be a Jini lookup service that did the communication an entirely different way (say, handed back a proxy that contained all of the contents of the lookup service, that was informed about changes but dealt with all requests from a client locally to that client) and that would be a fine implementation of the service. As long as it follows the spec, how it does so is up to the implementation (and the implementor).
>>
>> One of the points of the original Jini design was to make the wire protocol part of the implementation rather than part of the specification. And that's why what you have been seeing is not in the spec...
>>
>> Jim Waldo
>>
>> Note that this mail address will disappear sometime in the near future. Please update your address book with my new address, jim.waldo@oracle.com
>>
>> On Mar 26, 2010, at 1:32 PM, helcio silva wrote:
>>
>>> Hi, gentlemen.
>>>
>>> I am very happy with all this conversation. In fact, there are some
>>> "black holes" in JINI specification. This is only my opinion, and I do
>>> not put it as an universal truth...
>>>
>>> Regarding the PDU itself, I will try to decode it using the RMI
>>> specification. Thanks all by clarifications.
>>>
>>> I would like to expose some facts about that PDU and others. Those
>>> facts are result of observations performed by me when using wireshark
>>> to capture packets from wire.
>>>
>>> First of all, when a LUS receives a MRP request sent by a client,
>>> that LUS opens a TCP connection with that client. The TCP port used by
>>> client is that present on MRP request, as it can be seen on the MRP
>>> specification.
>>>
>>> After establishment of that TCP connection, two PDU are exchanged.
>>> Initially, the client sends a PDU composed by 4 Bytes (in my captures,
>>> those 4 Bytes are 00 00 00 01). I don't know EXACTLY what they mean
>>> (would be a version number?) So, the LUS sends the PDU posted by me
>>> in the first email. Similarly, I don't know EXACTLY what it means.
>>> Although I have an idea, I don't know what mean all its fields. The
>>> TCP connection is then finished.
>>>
>>> After that, a new connection is opened between the client and the
>>> Web server responsible by reggie-dl.jar and jsk-dl.jar files. The
>>> client sends an HTTP request, using the HEAD method and directed to
>>> reggie-dl.jar file. Then, It receives an HTTP response and the TCP
>>> connection is closed.
>>>
>>> Another TCP connection is established between the client and the
>>> Web server. A new HTTP request is sent by client, using the GET method
>>> and directed to reggie-dl.jar file. That file is downloaded by client.
>>> An interesting fact, gentlemen: the reggie-dl.jar file has 58060 B,
>>> and the MSS (Maximum Segment Size) for a machine beloging to an
>>> Ethernet segment is 1448 B. Therefore, there is need for 41 HTTP
>>> response PDUs to transport that file from Web server to client. After
>>> download is complete, the TCP connection is closed.
>>>
>>> Finally, a new TCP connection is established between the same
>>> components. This time, however, the client sends an HTTP request to
>>> download the jsk-dl.jar file. Similarly, there is need for more than
>>> one HTTP PDU to do it. More specifically, the jsk-dl.jar file has
>>> 63997 B. Using 1448 B as MSS, we can see (I saw, believe!) that there
>>> are need for 45 HTTP response PDUs to download that file.
>>>
>>> When watching the JINI protocols specification, I didn't find any
>>> information about I exposed above.
>>>
>>> Thanks again, gentlemen.
>>>
>>> Helcio.
>>>
>>> 2010/3/26 Alfredo Ramos <al...@rayamos.com>:
>>>> On 26 March 2010 09:35, Sim IJskes - QCG <si...@qcg.nl> wrote:
>>>>
>>>>> helcio silva wrote:
>>>>>
>>>>>> Second. I think the trace posted does not contain any serialized
>>>>>> class. As can be seen, there is much ascii codified text. For example,
>>>>>>
>>>>>
>>>>> Are you really, really sure?
>>>>>
>>>>>
>>>> Don't be mean, just tell him...
>>>>
>>>> That is a Serialized MarshalledObject that contains a remote reference to
>>>> the Registrar server hosted by the Lookup Discovery Service (i.e. reggie).
>>>> The http URLs you see as part of the packet are class annotations.
>>>>
>>>> It is in reality RMI serialization, JINI services are RMI servers, see
>>>> http://java.sun.com/j2se/1.4.2/docs/guide/rmi/spec/rmi-protocol4.html
>>>>
>>>> This package is normally a multicast response to a multicast request, but
>>>> could be also a response to a unicast discovery request (as it is used in
>>>> both cases).
>>>>
>>>> See more details at:
>>>> http://www.jini.org/wiki/Jini_Discovery_and_Join_Specification#The_Discovery_Protocols
>>>>
>>>> This package is the bit that reads:
>>>> "A multicast response client responds to callers, passing each a proxy that
>>>> allows it to communicate with its lookup service."
>>>>
>>>> Have fun,
>>>>
>>>> Alfredo Ramos
>>>>
>>
>>
Re: Help on to decode information encapsulated by TCP segment during
JINI discovery.
Posted by helcio silva <su...@gmail.com>.
Hi, Jim. I'm very happy to be talking to you, one of most important
participants on design of JINI architecture.
In fact, remembering of the concepts behind JINI, it makes all
sense the JINI protocols specification does not to contain the meaning
of that PDU shown. It is related to the reference implementation of
LUS (reggie), not to the standard itself.
Currently, I am working on evaluating JINI taking in account the
bandwidth comsuption. Thus, I need to know exactly what is going on
the wire. I can see now that those PDUs are related to the reference
implementation, not to standard itself, but I still want to know what
they mean.
Please, Jim, can you point to me where can I find some information
about the protocol developed for the LUS reference implementation?
Kindest regards to all, gentlemen.
Helcio.
2010/3/26 Jim Waldo <Ji...@sun.com>:
> Well, the reason that this information is not in the Jini specification is that it is an artifact of the particular Jini implementation, not something that defines the Jini system.
>
> What the specification says is that the lookup service will return a proxy to that service as part of discovery. That proxy will implement a particular Java interface, and will allow communication with the lookup service from the client. But the specification does not say how that communication is done; that is a private matter between the lookup service and the proxy handed out by the lookup service.
>
> By looking at the particular implementation, you have been able to find out a lot about how that communication is done in this pair of service and proxy. But there could be a Jini lookup service that did the communication an entirely different way (say, handed back a proxy that contained all of the contents of the lookup service, that was informed about changes but dealt with all requests from a client locally to that client) and that would be a fine implementation of the service. As long as it follows the spec, how it does so is up to the implementation (and the implementor).
>
> One of the points of the original Jini design was to make the wire protocol part of the implementation rather than part of the specification. And that's why what you have been seeing is not in the spec...
>
> Jim Waldo
>
> Note that this mail address will disappear sometime in the near future. Please update your address book with my new address, jim.waldo@oracle.com
>
> On Mar 26, 2010, at 1:32 PM, helcio silva wrote:
>
>> Hi, gentlemen.
>>
>> I am very happy with all this conversation. In fact, there are some
>> "black holes" in JINI specification. This is only my opinion, and I do
>> not put it as an universal truth...
>>
>> Regarding the PDU itself, I will try to decode it using the RMI
>> specification. Thanks all by clarifications.
>>
>> I would like to expose some facts about that PDU and others. Those
>> facts are result of observations performed by me when using wireshark
>> to capture packets from wire.
>>
>> First of all, when a LUS receives a MRP request sent by a client,
>> that LUS opens a TCP connection with that client. The TCP port used by
>> client is that present on MRP request, as it can be seen on the MRP
>> specification.
>>
>> After establishment of that TCP connection, two PDU are exchanged.
>> Initially, the client sends a PDU composed by 4 Bytes (in my captures,
>> those 4 Bytes are 00 00 00 01). I don't know EXACTLY what they mean
>> (would be a version number?) So, the LUS sends the PDU posted by me
>> in the first email. Similarly, I don't know EXACTLY what it means.
>> Although I have an idea, I don't know what mean all its fields. The
>> TCP connection is then finished.
>>
>> After that, a new connection is opened between the client and the
>> Web server responsible by reggie-dl.jar and jsk-dl.jar files. The
>> client sends an HTTP request, using the HEAD method and directed to
>> reggie-dl.jar file. Then, It receives an HTTP response and the TCP
>> connection is closed.
>>
>> Another TCP connection is established between the client and the
>> Web server. A new HTTP request is sent by client, using the GET method
>> and directed to reggie-dl.jar file. That file is downloaded by client.
>> An interesting fact, gentlemen: the reggie-dl.jar file has 58060 B,
>> and the MSS (Maximum Segment Size) for a machine beloging to an
>> Ethernet segment is 1448 B. Therefore, there is need for 41 HTTP
>> response PDUs to transport that file from Web server to client. After
>> download is complete, the TCP connection is closed.
>>
>> Finally, a new TCP connection is established between the same
>> components. This time, however, the client sends an HTTP request to
>> download the jsk-dl.jar file. Similarly, there is need for more than
>> one HTTP PDU to do it. More specifically, the jsk-dl.jar file has
>> 63997 B. Using 1448 B as MSS, we can see (I saw, believe!) that there
>> are need for 45 HTTP response PDUs to download that file.
>>
>> When watching the JINI protocols specification, I didn't find any
>> information about I exposed above.
>>
>> Thanks again, gentlemen.
>>
>> Helcio.
>>
>> 2010/3/26 Alfredo Ramos <al...@rayamos.com>:
>>> On 26 March 2010 09:35, Sim IJskes - QCG <si...@qcg.nl> wrote:
>>>
>>>> helcio silva wrote:
>>>>
>>>>> Second. I think the trace posted does not contain any serialized
>>>>> class. As can be seen, there is much ascii codified text. For example,
>>>>>
>>>>
>>>> Are you really, really sure?
>>>>
>>>>
>>> Don't be mean, just tell him...
>>>
>>> That is a Serialized MarshalledObject that contains a remote reference to
>>> the Registrar server hosted by the Lookup Discovery Service (i.e. reggie).
>>> The http URLs you see as part of the packet are class annotations.
>>>
>>> It is in reality RMI serialization, JINI services are RMI servers, see
>>> http://java.sun.com/j2se/1.4.2/docs/guide/rmi/spec/rmi-protocol4.html
>>>
>>> This package is normally a multicast response to a multicast request, but
>>> could be also a response to a unicast discovery request (as it is used in
>>> both cases).
>>>
>>> See more details at:
>>> http://www.jini.org/wiki/Jini_Discovery_and_Join_Specification#The_Discovery_Protocols
>>>
>>> This package is the bit that reads:
>>> "A multicast response client responds to callers, passing each a proxy that
>>> allows it to communicate with its lookup service."
>>>
>>> Have fun,
>>>
>>> Alfredo Ramos
>>>
>
>
Re: Help on to decode information encapsulated by TCP segment during
JINI discovery.
Posted by Jim Waldo <Ji...@Sun.COM>.
Well, the reason that this information is not in the Jini specification is that it is an artifact of the particular Jini implementation, not something that defines the Jini system.
What the specification says is that the lookup service will return a proxy to that service as part of discovery. That proxy will implement a particular Java interface, and will allow communication with the lookup service from the client. But the specification does not say how that communication is done; that is a private matter between the lookup service and the proxy handed out by the lookup service.
By looking at the particular implementation, you have been able to find out a lot about how that communication is done in this pair of service and proxy. But there could be a Jini lookup service that did the communication an entirely different way (say, handed back a proxy that contained all of the contents of the lookup service, that was informed about changes but dealt with all requests from a client locally to that client) and that would be a fine implementation of the service. As long as it follows the spec, how it does so is up to the implementation (and the implementor).
One of the points of the original Jini design was to make the wire protocol part of the implementation rather than part of the specification. And that's why what you have been seeing is not in the spec...
Jim Waldo
Note that this mail address will disappear sometime in the near future. Please update your address book with my new address, jim.waldo@oracle.com
On Mar 26, 2010, at 1:32 PM, helcio silva wrote:
> Hi, gentlemen.
>
> I am very happy with all this conversation. In fact, there are some
> "black holes" in JINI specification. This is only my opinion, and I do
> not put it as an universal truth...
>
> Regarding the PDU itself, I will try to decode it using the RMI
> specification. Thanks all by clarifications.
>
> I would like to expose some facts about that PDU and others. Those
> facts are result of observations performed by me when using wireshark
> to capture packets from wire.
>
> First of all, when a LUS receives a MRP request sent by a client,
> that LUS opens a TCP connection with that client. The TCP port used by
> client is that present on MRP request, as it can be seen on the MRP
> specification.
>
> After establishment of that TCP connection, two PDU are exchanged.
> Initially, the client sends a PDU composed by 4 Bytes (in my captures,
> those 4 Bytes are 00 00 00 01). I don't know EXACTLY what they mean
> (would be a version number?) So, the LUS sends the PDU posted by me
> in the first email. Similarly, I don't know EXACTLY what it means.
> Although I have an idea, I don't know what mean all its fields. The
> TCP connection is then finished.
>
> After that, a new connection is opened between the client and the
> Web server responsible by reggie-dl.jar and jsk-dl.jar files. The
> client sends an HTTP request, using the HEAD method and directed to
> reggie-dl.jar file. Then, It receives an HTTP response and the TCP
> connection is closed.
>
> Another TCP connection is established between the client and the
> Web server. A new HTTP request is sent by client, using the GET method
> and directed to reggie-dl.jar file. That file is downloaded by client.
> An interesting fact, gentlemen: the reggie-dl.jar file has 58060 B,
> and the MSS (Maximum Segment Size) for a machine beloging to an
> Ethernet segment is 1448 B. Therefore, there is need for 41 HTTP
> response PDUs to transport that file from Web server to client. After
> download is complete, the TCP connection is closed.
>
> Finally, a new TCP connection is established between the same
> components. This time, however, the client sends an HTTP request to
> download the jsk-dl.jar file. Similarly, there is need for more than
> one HTTP PDU to do it. More specifically, the jsk-dl.jar file has
> 63997 B. Using 1448 B as MSS, we can see (I saw, believe!) that there
> are need for 45 HTTP response PDUs to download that file.
>
> When watching the JINI protocols specification, I didn't find any
> information about I exposed above.
>
> Thanks again, gentlemen.
>
> Helcio.
>
> 2010/3/26 Alfredo Ramos <al...@rayamos.com>:
>> On 26 March 2010 09:35, Sim IJskes - QCG <si...@qcg.nl> wrote:
>>
>>> helcio silva wrote:
>>>
>>>> Second. I think the trace posted does not contain any serialized
>>>> class. As can be seen, there is much ascii codified text. For example,
>>>>
>>>
>>> Are you really, really sure?
>>>
>>>
>> Don't be mean, just tell him...
>>
>> That is a Serialized MarshalledObject that contains a remote reference to
>> the Registrar server hosted by the Lookup Discovery Service (i.e. reggie).
>> The http URLs you see as part of the packet are class annotations.
>>
>> It is in reality RMI serialization, JINI services are RMI servers, see
>> http://java.sun.com/j2se/1.4.2/docs/guide/rmi/spec/rmi-protocol4.html
>>
>> This package is normally a multicast response to a multicast request, but
>> could be also a response to a unicast discovery request (as it is used in
>> both cases).
>>
>> See more details at:
>> http://www.jini.org/wiki/Jini_Discovery_and_Join_Specification#The_Discovery_Protocols
>>
>> This package is the bit that reads:
>> "A multicast response client responds to callers, passing each a proxy that
>> allows it to communicate with its lookup service."
>>
>> Have fun,
>>
>> Alfredo Ramos
>>
Re: Help on to decode information encapsulated by TCP segment during
JINI discovery.
Posted by helcio silva <su...@gmail.com>.
Hello to everybody.
I agree that I can use the specification to discover the syntax of
the exchanged data. Its semantics, however, can not be exactly
understood only by watching those data. In effect, I really need of
the protocol specification.
For example, there is a message that contains only four bytes, named
00 00 00 01. Are those bytes related to the number of version of
discovery protocol? I guess, but I am not sure about it. By the way,
the protocol specification present on JINI pages does not contains
anything about it, because it is related to the reference
implementation, not to the standard itself...
I also agree that the bandwidth comsuption will be defined by
communication between client and service. But I still believe that it
is interesting to know how much bandwidth is comsumed during that
setup phase.
Well, I will watch the java serialization object specification. When
I find some interesting stuff, I will post it on forum.
Kindest regards to all, gentlemen.
Helcio.
2010/3/26 Sim IJskes - QCG <si...@qcg.nl>:
> On 03/26/2010 06:32 PM, helcio silva wrote:
>>
>> When watching the JINI protocols specification, I didn't find any
>> information about I exposed above.
>
> You really need to read: Java Object Serialization Specification; Object
> Serialization Stream Protocol.
>
> With this specification and the class source files from jini, you can decode
> all the data you've captured.
>
> Gr. Sim
>
>
>
>
Re: Help on to decode information encapsulated by TCP segment during
JINI discovery.
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 03/26/2010 06:32 PM, helcio silva wrote:
> When watching the JINI protocols specification, I didn't find any
> information about I exposed above.
You really need to read: Java Object Serialization Specification; Object
Serialization Stream Protocol.
With this specification and the class source files from jini, you can
decode all the data you've captured.
Gr. Sim
Re: Help on to decode information encapsulated by TCP segment during
JINI discovery.
Posted by helcio silva <su...@gmail.com>.
Hi, gentlemen.
I am very happy with all this conversation. In fact, there are some
"black holes" in JINI specification. This is only my opinion, and I do
not put it as an universal truth...
Regarding the PDU itself, I will try to decode it using the RMI
specification. Thanks all by clarifications.
I would like to expose some facts about that PDU and others. Those
facts are result of observations performed by me when using wireshark
to capture packets from wire.
First of all, when a LUS receives a MRP request sent by a client,
that LUS opens a TCP connection with that client. The TCP port used by
client is that present on MRP request, as it can be seen on the MRP
specification.
After establishment of that TCP connection, two PDU are exchanged.
Initially, the client sends a PDU composed by 4 Bytes (in my captures,
those 4 Bytes are 00 00 00 01). I don't know EXACTLY what they mean
(would be a version number?) So, the LUS sends the PDU posted by me
in the first email. Similarly, I don't know EXACTLY what it means.
Although I have an idea, I don't know what mean all its fields. The
TCP connection is then finished.
After that, a new connection is opened between the client and the
Web server responsible by reggie-dl.jar and jsk-dl.jar files. The
client sends an HTTP request, using the HEAD method and directed to
reggie-dl.jar file. Then, It receives an HTTP response and the TCP
connection is closed.
Another TCP connection is established between the client and the
Web server. A new HTTP request is sent by client, using the GET method
and directed to reggie-dl.jar file. That file is downloaded by client.
An interesting fact, gentlemen: the reggie-dl.jar file has 58060 B,
and the MSS (Maximum Segment Size) for a machine beloging to an
Ethernet segment is 1448 B. Therefore, there is need for 41 HTTP
response PDUs to transport that file from Web server to client. After
download is complete, the TCP connection is closed.
Finally, a new TCP connection is established between the same
components. This time, however, the client sends an HTTP request to
download the jsk-dl.jar file. Similarly, there is need for more than
one HTTP PDU to do it. More specifically, the jsk-dl.jar file has
63997 B. Using 1448 B as MSS, we can see (I saw, believe!) that there
are need for 45 HTTP response PDUs to download that file.
When watching the JINI protocols specification, I didn't find any
information about I exposed above.
Thanks again, gentlemen.
Helcio.
2010/3/26 Alfredo Ramos <al...@rayamos.com>:
> On 26 March 2010 09:35, Sim IJskes - QCG <si...@qcg.nl> wrote:
>
>> helcio silva wrote:
>>
>>> Second. I think the trace posted does not contain any serialized
>>> class. As can be seen, there is much ascii codified text. For example,
>>>
>>
>> Are you really, really sure?
>>
>>
> Don't be mean, just tell him...
>
> That is a Serialized MarshalledObject that contains a remote reference to
> the Registrar server hosted by the Lookup Discovery Service (i.e. reggie).
> The http URLs you see as part of the packet are class annotations.
>
> It is in reality RMI serialization, JINI services are RMI servers, see
> http://java.sun.com/j2se/1.4.2/docs/guide/rmi/spec/rmi-protocol4.html
>
> This package is normally a multicast response to a multicast request, but
> could be also a response to a unicast discovery request (as it is used in
> both cases).
>
> See more details at:
> http://www.jini.org/wiki/Jini_Discovery_and_Join_Specification#The_Discovery_Protocols
>
> This package is the bit that reads:
> "A multicast response client responds to callers, passing each a proxy that
> allows it to communicate with its lookup service."
>
> Have fun,
>
> Alfredo Ramos
>
Re: Help on to decode information encapsulated by TCP segment during
JINI discovery.
Posted by Alfredo Ramos <al...@rayamos.com>.
On 26 March 2010 09:35, Sim IJskes - QCG <si...@qcg.nl> wrote:
> helcio silva wrote:
>
>> Second. I think the trace posted does not contain any serialized
>> class. As can be seen, there is much ascii codified text. For example,
>>
>
> Are you really, really sure?
>
>
Don't be mean, just tell him...
That is a Serialized MarshalledObject that contains a remote reference to
the Registrar server hosted by the Lookup Discovery Service (i.e. reggie).
The http URLs you see as part of the packet are class annotations.
It is in reality RMI serialization, JINI services are RMI servers, see
http://java.sun.com/j2se/1.4.2/docs/guide/rmi/spec/rmi-protocol4.html
This package is normally a multicast response to a multicast request, but
could be also a response to a unicast discovery request (as it is used in
both cases).
See more details at:
http://www.jini.org/wiki/Jini_Discovery_and_Join_Specification#The_Discovery_Protocols
This package is the bit that reads:
"A multicast response client responds to callers, passing each a proxy that
allows it to communicate with its lookup service."
Have fun,
Alfredo Ramos
Re: Help on to decode information encapsulated by TCP segment during
JINI discovery.
Posted by Sim IJskes - QCG <si...@qcg.nl>.
helcio silva wrote:
> Second. I think the trace posted does not contain any serialized
> class. As can be seen, there is much ascii codified text. For example,
Are you really, really sure?
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Leiden: 28088397
Re: Help on to decode information encapsulated by TCP segment during
JINI discovery.
Posted by helcio silva <su...@gmail.com>.
Hi, gentlemen. Well, my question remains. However, I would like to
do some comments.
First of all, I am using wireshark to capture data, Thus, there is
no need for use of SNMP protocol. My question is related to the format
used by LUS to provide information to clients about where its proxy
can be downloaded.
Second. I think the trace posted does not contain any serialized
class. As can be seen, there is much ascii codified text. For example,
we can to see:
- java.rmi.MarshalledObject;
- http://172.17.3.162:8080/reggie-dl.jar
- http://172.17.3.162:8080/jsk-dl.jar
- com.sun.jini.reggie.RegistrarProxy
- com/sun/jini/reggie/Registrar
- com.sun.jini.reggie.RegistrarImpl_Stub
- java.rmi.server.RemoteStub
- java.rmi.server.RemoteObject
- public
Some field of that PDU can be deducted (for example,
http://172.17.3.162:8080/reggie-dl.jar is used to tell to client where
it can download reggie-dl.jar). But I do not know what mean those
field that can not be viewed on trace shown, because they are not
ascii codified.
Additionally, I would like to know why clients send TWO MRP
requests at a time. Why not to send an only one? The same fact can be
viewed on MAP announces. Failure tolerance? Is this a standard issue,
or is it related to the (reference) implementation of protocols?
Kindest regards, gentlemen.
Helcio.
2010/3/24 Luis Arce <ma...@hotmail.com>:
>
> Helcio,
> You can configure SNMP protocol in your machines and then install on a server a NMS(Network Management Server), like SNMPc www.castlerock.com (use demo license) or nagios for capture the data traffic and view with a graphic the result.
> Best regards,
> Luis Arce
>
>> Date: Tue, 23 Mar 2010 19:14:03 -0300
>> Subject: Help on to decode information encapsulated by TCP segment during JINI discovery.
>> From: sunnywheatherbb@gmail.com
>> To: river-user@incubator.apache.org
>>
>> Hello, gentlemen. How are you?
>>
>> Well, I'm interested in to investigate the bandwidth consumed by
>> JINI applications. In order to do it, I'm using wireshark to capture
>> some PDUs (Packet Data Units) from wire. So, I've captured the
>> following application layer PDU:
>>
>> 0000 ac ed 00 05 73 72 00 19 6a 61 76 61 2e 72 6d 69 ....sr..java.rmi
>> 0010 2e 4d 61 72 73 68 61 6c 6c 65 64 4f 62 6a 65 63 .MarshalledObjec
>> 0020 74 7c bd 1e 97 ed 63 fc 3e 02 00 03 49 00 04 68 t|....c.>...I..h
>> 0030 61 73 68 5b 00 08 6c 6f 63 42 79 74 65 73 74 00 ash[..locBytest.
>> 0040 02 5b 42 5b 00 08 6f 62 6a 42 79 74 65 73 71 00 .[B[..objBytesq.
>> 0050 7e 00 01 78 70 43 71 e8 93 75 72 00 02 5b 42 ac ~..xpCq..ur..[B.
>> 0060 f3 17 f8 06 08 54 e0 02 00 00 78 70 00 00 00 58 .....T....xp...X
>> 0070 ac ed 00 05 74 00 4a 68 74 74 70 3a 2f 2f 31 37 ....t.Jhttp://17
>> 0080 32 2e 31 37 2e 33 2e 31 36 32 3a 38 30 38 30 2f 2.17.3.162:8080/
>> 0090 72 65 67 67 69 65 2d 64 6c 2e 6a 61 72 20 68 74 reggie-dl.jar ht
>> 00a0 74 70 3a 2f 2f 31 37 32 2e 31 37 2e 33 2e 31 36 tp://172.17.3.16
>> 00b0 32 3a 38 30 38 30 2f 6a 73 6b 2d 64 6c 2e 6a 61 2:8080/jsk-dl.ja
>> 00c0 72 71 00 7e 00 00 70 70 75 71 00 7e 00 03 00 00 rq.~..ppuq.~....
>> 00d0 01 3a ac ed 00 05 73 72 00 22 63 6f 6d 2e 73 75 .:....sr."com.su
>> 00e0 6e 2e 6a 69 6e 69 2e 72 65 67 67 69 65 2e 52 65 n.jini.reggie.Re
>> 00f0 67 69 73 74 72 61 72 50 72 6f 78 79 00 00 00 00 gistrarProxy....
>> 0100 00 00 00 02 03 00 01 4c 00 06 73 65 72 76 65 72 .......L..server
>> 0110 74 00 1f 4c 63 6f 6d 2f 73 75 6e 2f 6a 69 6e 69 t..Lcom/sun/jini
>> 0120 2f 72 65 67 67 69 65 2f 52 65 67 69 73 74 72 61 /reggie/Registra
>> 0130 72 3b 78 70 73 72 00 26 63 6f 6d 2e 73 75 6e 2e r;xpsr.&com.sun.
>> 0140 6a 69 6e 69 2e 72 65 67 67 69 65 2e 52 65 67 69 jini.reggie.Regi
>> 0150 73 74 72 61 72 49 6d 70 6c 5f 53 74 75 62 00 00 strarImpl_Stub..
>> 0160 00 00 00 00 00 02 02 00 00 78 72 00 1a 6a 61 76 .........xr..jav
>> 0170 61 2e 72 6d 69 2e 73 65 72 76 65 72 2e 52 65 6d a.rmi.server.Rem
>> 0180 6f 74 65 53 74 75 62 e9 fe dc c9 8b e1 65 1a 02 oteStub......e..
>> 0190 00 00 78 72 00 1c 6a 61 76 61 2e 72 6d 69 2e 73 ..xr..java.rmi.s
>> 01a0 65 72 76 65 72 2e 52 65 6d 6f 74 65 4f 62 6a 65 erver.RemoteObje
>> 01b0 63 74 d3 61 b4 91 0c 61 33 1e 03 00 00 78 70 77 ct.a...a3....xpw
>> 01c0 37 00 0b 55 6e 69 63 61 73 74 52 65 66 32 00 00 7..UnicastRef2..
>> 01d0 0c 31 37 32 2e 31 37 2e 33 2e 31 36 32 00 00 af .172.17.3.162...
>> 01e0 a3 b6 8b af e2 22 c4 2b 9f b0 19 e3 dd 00 00 01 .....".+........
>> 01f0 28 2b f3 bb c1 80 01 00 78 77 10 20 f5 a8 9b 3f (+......xw. ...?
>> 0200 64 46 93 b5 69 33 f9 5f 39 37 24 78 77 0c 00 00 dF..i3._97$xw...
>> 0210 00 01 00 06 70 75 62 6c 69 63 ....public
>>
>> The printable characters give some glue about what is going on. As
>> a matter of fact, the PDU above is sent by reggie to a client to
>> provide information related where that client can download a proxy to
>> it (reggie). In the JINI specification we can find the format for
>> discovery requests sent by clients, as well the announces performed by
>> Lookup Services. But I can't find a precise definition for this kind
>> of PDU above. Does somebody can help me?
>>
>> Thanks in advance, gentlemen!!!
>>
>> Helcio.
>
> _________________________________________________________________
> Mira tus emails ¡cuando te llegan! Hotmail actualiza tu bandeja de entrada automáticamente. Ver más
> http://www.descubrewindowslive.com/hotmail/actualizacion-guardado.asp
RE: Help on to decode information encapsulated by TCP segment
during JINI discovery.
Posted by Luis Arce <ma...@hotmail.com>.
Helcio,
You can configure SNMP protocol in your machines and then install on a server a NMS(Network Management Server), like SNMPc www.castlerock.com (use demo license) or nagios for capture the data traffic and view with a graphic the result.
Best regards,
Luis Arce
> Date: Tue, 23 Mar 2010 19:14:03 -0300
> Subject: Help on to decode information encapsulated by TCP segment during JINI discovery.
> From: sunnywheatherbb@gmail.com
> To: river-user@incubator.apache.org
>
> Hello, gentlemen. How are you?
>
> Well, I'm interested in to investigate the bandwidth consumed by
> JINI applications. In order to do it, I'm using wireshark to capture
> some PDUs (Packet Data Units) from wire. So, I've captured the
> following application layer PDU:
>
> 0000 ac ed 00 05 73 72 00 19 6a 61 76 61 2e 72 6d 69 ....sr..java.rmi
> 0010 2e 4d 61 72 73 68 61 6c 6c 65 64 4f 62 6a 65 63 .MarshalledObjec
> 0020 74 7c bd 1e 97 ed 63 fc 3e 02 00 03 49 00 04 68 t|....c.>...I..h
> 0030 61 73 68 5b 00 08 6c 6f 63 42 79 74 65 73 74 00 ash[..locBytest.
> 0040 02 5b 42 5b 00 08 6f 62 6a 42 79 74 65 73 71 00 .[B[..objBytesq.
> 0050 7e 00 01 78 70 43 71 e8 93 75 72 00 02 5b 42 ac ~..xpCq..ur..[B.
> 0060 f3 17 f8 06 08 54 e0 02 00 00 78 70 00 00 00 58 .....T....xp...X
> 0070 ac ed 00 05 74 00 4a 68 74 74 70 3a 2f 2f 31 37 ....t.Jhttp://17
> 0080 32 2e 31 37 2e 33 2e 31 36 32 3a 38 30 38 30 2f 2.17.3.162:8080/
> 0090 72 65 67 67 69 65 2d 64 6c 2e 6a 61 72 20 68 74 reggie-dl.jar ht
> 00a0 74 70 3a 2f 2f 31 37 32 2e 31 37 2e 33 2e 31 36 tp://172.17.3.16
> 00b0 32 3a 38 30 38 30 2f 6a 73 6b 2d 64 6c 2e 6a 61 2:8080/jsk-dl.ja
> 00c0 72 71 00 7e 00 00 70 70 75 71 00 7e 00 03 00 00 rq.~..ppuq.~....
> 00d0 01 3a ac ed 00 05 73 72 00 22 63 6f 6d 2e 73 75 .:....sr."com.su
> 00e0 6e 2e 6a 69 6e 69 2e 72 65 67 67 69 65 2e 52 65 n.jini.reggie.Re
> 00f0 67 69 73 74 72 61 72 50 72 6f 78 79 00 00 00 00 gistrarProxy....
> 0100 00 00 00 02 03 00 01 4c 00 06 73 65 72 76 65 72 .......L..server
> 0110 74 00 1f 4c 63 6f 6d 2f 73 75 6e 2f 6a 69 6e 69 t..Lcom/sun/jini
> 0120 2f 72 65 67 67 69 65 2f 52 65 67 69 73 74 72 61 /reggie/Registra
> 0130 72 3b 78 70 73 72 00 26 63 6f 6d 2e 73 75 6e 2e r;xpsr.&com.sun.
> 0140 6a 69 6e 69 2e 72 65 67 67 69 65 2e 52 65 67 69 jini.reggie.Regi
> 0150 73 74 72 61 72 49 6d 70 6c 5f 53 74 75 62 00 00 strarImpl_Stub..
> 0160 00 00 00 00 00 02 02 00 00 78 72 00 1a 6a 61 76 .........xr..jav
> 0170 61 2e 72 6d 69 2e 73 65 72 76 65 72 2e 52 65 6d a.rmi.server.Rem
> 0180 6f 74 65 53 74 75 62 e9 fe dc c9 8b e1 65 1a 02 oteStub......e..
> 0190 00 00 78 72 00 1c 6a 61 76 61 2e 72 6d 69 2e 73 ..xr..java.rmi.s
> 01a0 65 72 76 65 72 2e 52 65 6d 6f 74 65 4f 62 6a 65 erver.RemoteObje
> 01b0 63 74 d3 61 b4 91 0c 61 33 1e 03 00 00 78 70 77 ct.a...a3....xpw
> 01c0 37 00 0b 55 6e 69 63 61 73 74 52 65 66 32 00 00 7..UnicastRef2..
> 01d0 0c 31 37 32 2e 31 37 2e 33 2e 31 36 32 00 00 af .172.17.3.162...
> 01e0 a3 b6 8b af e2 22 c4 2b 9f b0 19 e3 dd 00 00 01 .....".+........
> 01f0 28 2b f3 bb c1 80 01 00 78 77 10 20 f5 a8 9b 3f (+......xw. ...?
> 0200 64 46 93 b5 69 33 f9 5f 39 37 24 78 77 0c 00 00 dF..i3._97$xw...
> 0210 00 01 00 06 70 75 62 6c 69 63 ....public
>
> The printable characters give some glue about what is going on. As
> a matter of fact, the PDU above is sent by reggie to a client to
> provide information related where that client can download a proxy to
> it (reggie). In the JINI specification we can find the format for
> discovery requests sent by clients, as well the announces performed by
> Lookup Services. But I can't find a precise definition for this kind
> of PDU above. Does somebody can help me?
>
> Thanks in advance, gentlemen!!!
>
> Helcio.
_________________________________________________________________
Mira tus emails ¡cuando te llegan! Hotmail actualiza tu bandeja de entrada automáticamente. Ver más
http://www.descubrewindowslive.com/hotmail/actualizacion-guardado.asp
Re: Help on to decode information encapsulated by TCP segment during
JINI discovery.
Posted by Sim IJskes - QCG <si...@qcg.nl>.
helcio silva wrote:
> Well, I'm interested in to investigate the bandwidth consumed by
> JINI applications. In order to do it, I'm using wireshark to capture
> Lookup Services. But I can't find a precise definition for this kind
> of PDU above. Does somebody can help me?
Have you read:
Java Object Serialization Specification
version 6.0
chapter: Object Serialization Stream Protocol
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Leiden: 28088397