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.wa...@sun.com [mailto:jim.wa...@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 <jim.wa...@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.wa...@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 <alfredo.pub...@rayamos.com>: > >>>>> On 26 March 2010 09:35, Sim IJskes - QCG <s...@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 > >>>>> > >>> > >>> > > >
