Vinay, Yes you are right BEEP looks better. There is a BSD impl on SF :- http://sourceforge.net/projects/beepcore-java/
I don't think it is an issue for Request/Reply as it is a layer between AltrmiInvocationHandler and the true streaming mechanism... - Paul >Hi, >dghmux seems kewl, >However BEEP addresses this in a >much broader and *standard* compliant way . >It even has a tunnel 'profile' to take care >of the NAT issues too . >This might be viral to the Altrmi codebase as >it might influence the way Request/Reply objects are >sent across the wire ..(not sure though).. > >Any BEEP experts who can throw light here ?? > >Regards, >V i n a y. > >--- Paul Hammant <[EMAIL PROTECTED]> wrote: > >> Folks, >> >>To solve the callback feature for AltRMI.... This >>was the sourceforge >>project : >> >> http://dghmux-java.sourceforge.net/ >> >>It is LGPL which is OKish for Apache use. >>I kinda prefer two connections though, if the client >>opens both then >>there are no NAT problems. >>The OpenConnectionRequest class could be expanded to >>have a parameter >>that indicates server-is-listener or >>client-is-listener. >> >>Thoughts? >> >>- Paul >> >> >>-- >>To unsubscribe, e-mail: >><mailto:[EMAIL PROTECTED]> >>For additional commands, e-mail: >><mailto:[EMAIL PROTECTED]> >> > > >__________________________________________________ >Do You Yahoo!? >Yahoo! Sports - Coverage of the 2002 Olympic Games >http://sports.yahoo.com > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
