You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@river.apache.org by Jim Waldo <Ji...@Sun.COM> on 2010/03/26 18:52:47 UTC
Re: Help on to decode information encapsulated by TCP segment during
JINI discovery.
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 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
>>>
>
>