You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Paul Hammant <Pa...@yahoo.com> on 2002/02/20 23:51:13 UTC
[AltRMI] multiplexing over single connection
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AltRMI] (PATCH) BEEP wire
Posted by vinaysahil chandran <sa...@yahoo.com>.
Paul,
My understandin was that XML exchanges were
carried out to establish a session and henceforth
its header+payload traveling back and forth..
I admit there would be some extra header info
being passed here and there and
moreover some sync' issues , but never
expected the performance to this low.
I shall _try_ looking into BEEP more.
The work I did was a quick craft
of what I could gather from a lone example and the RFC
.
But as u mentioned writing our-own custom
Multiplexer or the one from sourceforge
(hope there are no license issues ) can be our other
options ..
Regards,
V i n a y.
--- Paul Hammant <Pa...@yahoo.com> wrote:
> Vinay,
>
> >Hi Paul,
> >We need a xml parser too along with beep
> libraries,
> >since BEEP exchanges xml messages
> > between peers to manage the channels/sessions
> >between the peers .
> >So maybe we can put xerces in /lib folder too..
> >
> I did not know it depended on XML parsing. It's
> only a multiplexer of
> byte streams, why did they need XML? Something
> lower tech would have
> been more appropriate.
>
> >Another favor , can you try benchmarking
> >BEEP with others in your 'PROPOSAL' .
> >Lets see how that fares as well .. ..
> >(I think it should do pretty well)
> >
> Well here is the speed:
>
> CustomStream over BEEP over sockets - 1000
> invocations per second
>
> Compare that to:
>
> CustomStream over sockets 8000 per second.
> ObjectStream over sockets 10000 per second.
>
> I think the speed is fairly poor. I was expecting a
> 10% speed drop, but
> this is 90% Vinay. Thatnks for doing the
> integration, Vinay, but I
> think we'll be evolving our own multiplexer that is
> faster. I have had
> a quick look and cannot see a flush() method that
> may speed it up.
>
> What are you thoughts dude?
>
> Regards,
>
> - Paul
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AltRMI] (PATCH) BEEP wire
Posted by Paul Hammant <Pa...@yahoo.com>.
Vinay,
>Hi Paul,
>We need a xml parser too along with beep libraries,
>since BEEP exchanges xml messages
> between peers to manage the channels/sessions
>between the peers .
>So maybe we can put xerces in /lib folder too..
>
I did not know it depended on XML parsing. It's only a multiplexer of
byte streams, why did they need XML? Something lower tech would have
been more appropriate.
>Another favor , can you try benchmarking
>BEEP with others in your 'PROPOSAL' .
>Lets see how that fares as well .. ..
>(I think it should do pretty well)
>
Well here is the speed:
CustomStream over BEEP over sockets - 1000 invocations per second
Compare that to:
CustomStream over sockets 8000 per second.
ObjectStream over sockets 10000 per second.
I think the speed is fairly poor. I was expecting a 10% speed drop, but
this is 90% Vinay. Thatnks for doing the integration, Vinay, but I
think we'll be evolving our own multiplexer that is faster. I have had
a quick look and cannot see a flush() method that may speed it up.
What are you thoughts dude?
Regards,
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AltRMI] (PATCH) BEEP wire
Posted by vinaysahil chandran <sa...@yahoo.com>.
Hi Paul,
We need a xml parser too along with beep libraries,
since BEEP exchanges xml messages
between peers to manage the channels/sessions
between the peers .
So maybe we can put xerces in /lib folder too..
Another favor , can you try benchmarking
BEEP with others in your 'PROPOSAL' .
Lets see how that fares as well .. ..
(I think it should do pretty well)
Thanks,
V i n a y
--- Paul Hammant <Pa...@yahoo.com> wrote:
> Vinay,
>
> Committed dude. When you next do a zip of source
> for me, can you leave
> out the cvs dirs ;-) Cheers dude :-)
>
> >Hi Paul,
> >....Presenting the BEEP transport layer for AltRMI
> >....
> >
> >NEW PACKAGES:
> >org.apache.commons.altrmi.client.impl.beep.*
> >org.apache.commons.altrmi.server.impl.beep.*
> >
> >For now I have built an independent test
> >suite(BeepClient/ServerTest),
> >but I guess this can be merged onto
> >SocketClient/ServerTest suite too ....
> >
> >Ant script puts the /lib folder into the classpath
> >, and thats where the beep library (beepcore.jar)
> >& xerces wud go ..
> >(Haven't attached the libraries here though .)
> >
> >tests2.xml have been updated with the
> >'beep-serve' and 'beep-client' targets too ..
> >(This time I have NO batch files :-)) )
> >
> he he :-)
>
> >We can benchmark it with Socket layer too.
> >(It might performs well too compared to
> >the '2 socket connection' approach when
> >callbacks come into picture..)
> >
> I see that you have a complete BEEP Factory and
> HostContext. That's a
> lot of work you have done. Some reading for me to
> do later!
>
> Question for others : If we include a BSD licensed
> jar (to compile
> against and resitribute) do we have to include it's
> license too... or
> just credit the origin.
>
> Regards,
>
> - Paul
>
> >
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AltRMI] (PATCH) BEEP wire
Posted by Paul Hammant <Pa...@yahoo.com>.
Vinay,
Committed dude. When you next do a zip of source for me, can you leave
out the cvs dirs ;-) Cheers dude :-)
>Hi Paul,
>....Presenting the BEEP transport layer for AltRMI
>....
>
>NEW PACKAGES:
>org.apache.commons.altrmi.client.impl.beep.*
>org.apache.commons.altrmi.server.impl.beep.*
>
>For now I have built an independent test
>suite(BeepClient/ServerTest),
>but I guess this can be merged onto
>SocketClient/ServerTest suite too ....
>
>Ant script puts the /lib folder into the classpath
>, and thats where the beep library (beepcore.jar)
>& xerces wud go ..
>(Haven't attached the libraries here though .)
>
>tests2.xml have been updated with the
>'beep-serve' and 'beep-client' targets too ..
>(This time I have NO batch files :-)) )
>
he he :-)
>We can benchmark it with Socket layer too.
>(It might performs well too compared to
>the '2 socket connection' approach when
>callbacks come into picture..)
>
I see that you have a complete BEEP Factory and HostContext. That's a
lot of work you have done. Some reading for me to do later!
Question for others : If we include a BSD licensed jar (to compile
against and resitribute) do we have to include it's license too... or
just credit the origin.
Regards,
- Paul
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[AltRMI] (PATCH) BEEP wire
Posted by vinaysahil chandran <sa...@yahoo.com>.
Hi Paul,
....Presenting the BEEP transport layer for AltRMI
....
NEW PACKAGES:
org.apache.commons.altrmi.client.impl.beep.*
org.apache.commons.altrmi.server.impl.beep.*
For now I have built an independent test
suite(BeepClient/ServerTest),
but I guess this can be merged onto
SocketClient/ServerTest suite too ....
Ant script puts the /lib folder into the classpath
, and thats where the beep library (beepcore.jar)
& xerces wud go ..
(Haven't attached the libraries here though .)
tests2.xml have been updated with the
'beep-serve' and 'beep-client' targets too ..
(This time I have NO batch files :-)) )
We can benchmark it with Socket layer too.
(It might performs well too compared to
the '2 socket connection' approach when
callbacks come into picture..)
way to go ... >
Regards,
V i n a y.
--- vinaysahil chandran <sa...@yahoo.com> wrote:
> > Hey dude, you're scaring me with RMI interfaces!
> >
> Sorry not my intention but somehow couldn't
> stop thinking of this example over Altrmi
> without much of an modification...
>
> > Pub/Sub is just an fancy name for callbacks not
> so?
> > Are we not talking
> > about the same thing?
> >
> We are ...
> Maybe I was dragging myself into the BEEP paradigm
> and trying to put its possibilities to some
> form of solid form ..
> Will sent the BEEP'ing files when I am done ..
> Regards,
> V i n a y.
> > - Paul
>
>
> >
> >
> > --
> > To unsubscribe, e-mail:
> >
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Sports - Coverage of the 2002 Olympic Games
> http://sports.yahoo.com
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
Re: [AltRMI] multiplexing over single connection
Posted by vinaysahil chandran <sa...@yahoo.com>.
> Hey dude, you're scaring me with RMI interfaces!
>
Sorry not my intention but somehow couldn't
stop thinking of this example over Altrmi
without much of an modification...
> Pub/Sub is just an fancy name for callbacks not so?
> Are we not talking
> about the same thing?
>
We are ...
Maybe I was dragging myself into the BEEP paradigm
and trying to put its possibilities to some
form of solid form ..
Will sent the BEEP'ing files when I am done ..
Regards,
V i n a y.
> - Paul
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AltRMI] multiplexing over single connection
Posted by Paul Hammant <Pa...@yahoo.com>.
Vinay,
>Paul,
>I was aiming along the lines
>of UnicastRemoteObject.exportObject(Remote obj) .
>
>For the EventNotifier example I was trying
>to come with ,
>the Subscriber exports itself
>and passes the reference of it to the Server.
>Subscriber:
>// SubscriberInterface.java
>
>public interface SubscriberInterface
> extends java.rmi.Remote {
> void inform(Event event) throws
> java.rmi.RemoteException;
>}
>
Hey dude, you're scaring me with RMI interfaces!
>And ConcreteSubscriber does something like
>ConcreteSub()
>{
>UnicastRemoteObject.exportObject(this);
>}
>
>
>So what you are proposing with PropertyChangeListeners
>
It was just an example of a use of call-back.
>would also work in my scenario too since there I
>would be passing the PropertyChangeListener
>objs to the server rather than a custom
>Subscriber_stub.
>
>But this was the direction I was coming from ...
>
>comments.?
>
Publish/Subscriber heh? I think you know more about where you want to
go with this than I do.
Pub/Sub is just an fancy name for callbacks not so? Are we not talking
about the same thing?
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AltRMI] multiplexing over single connection
Posted by vinaysahil chandran <sa...@yahoo.com>.
Paul,
I was aiming along the lines
of UnicastRemoteObject.exportObject(Remote obj) .
For the EventNotifier example I was trying
to come with ,
the Subscriber exports itself
and passes the reference of it to the Server.
Subscriber:
// SubscriberInterface.java
public interface SubscriberInterface
extends java.rmi.Remote {
void inform(Event event) throws
java.rmi.RemoteException;
}
And ConcreteSubscriber does something like
ConcreteSub()
{
UnicastRemoteObject.exportObject(this);
}
So what you are proposing with PropertyChangeListeners
would also work in my scenario too since there I
would be passing the PropertyChangeListener
objs to the server rather than a custom
Subscriber_stub.
But this was the direction I was coming from ...
comments.?
V i n a y .
--- Paul Hammant <Pa...@yahoo.com> wrote:
> Vinay,
>
> >Paul,
> >So would the right place to export an Object
> >from an API standpoint be :
> >
> >AltrmiFactory.exposeObject(Object o);
> >
> You mean in the context of BEEP and the layer it
> represents inside AltRMI ?
>
> I don't quite understand what you are asking
> here....
> AltrmiFactory is a client-side class, you would not
> call anythin on it
> to publish (exposeObject is publishig right?).
>
> BEEP would be used to allow us to have listeners
> straddling two VMs.
> Consider the well understood
> PropertyChangeListener.
>
> Server side :
>
> interface XyzService {
> void addListener(PropertyChangeListener pcl);
> }
>
> Client side :
>
> class MyClient implements PropertyChangeListener {
>
> XyzService xyzService;
>
> public MyClient() {
> xyzService = lookup(".... // via AltRMI
> xyzService.addListener(this);
> }
>
> public void propertyChange(PropertyChangeEvent
> evt) {
> System.out.println("Server has performed
> callback - " + evt.toString());
> }
>
> }
>
> What we see there is the client reaching out to the
> server as usual
> (lookup), but then registering itself as a suitable
> listener.
> Completely asynchronously, the server can call the
> applicable method on
> the client, even if there is TCP/IP in the way. We
> need at least two
> channels open to do this. One (as we have now) to
> allow the client to
> invoke methods on the server and the second to allow
> async invokation of
> methods on the client from the server.
>
> - Paul
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Betwixt] ID-IDREF solution to cyclic reference problem
Posted by robert burrell donkin <ro...@mac.com>.
hi james
On Tuesday, February 26, 2002, at 05:33 AM, James Strachan wrote:
> From: "robert burrell donkin" <ro...@mac.com>
<snip>
>> i should probably say something about the changes to
>> org.apache.commons.betwixt.io.BeanWriter since they are quite extensive.
> i'
>> ve tried to separate the actual writing from the logic concerning
>> processing the descriptors . the writing code should now live in small
>> expressXXX methods and some duplication has been reduced.
>
> Cool.
>
> I've been musing over possible ways to make it easy for users of betwixt
> to
> 'walk' the XML tree for a certain bean. Maybe once there's a few different
> ways of outputting a bean, text, SAX & DOM (*) then we could maybe
> refactor
> the code to make it easier & share code. Just thinking aloud here...
this is pretty much what i was (am) thinking too :)
the logic's too complex to get right in different places without sharing.
i'd like to pull out all the logic into an abstract superclass which will
call expressXXX type methods. this should make it easier to implement
other ways of output since it should be clear which methods are required.
i agree that the signatures will be probably change a lot once we start
looking at different implementation but hopefully they'd give us some sort
of basis to start with.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Betwixt] ID-IDREF solution to cyclic reference problem
Posted by James Strachan <ja...@yahoo.co.uk>.
From: "robert burrell donkin" <ro...@mac.com>
> i've just committed code that stamps IDs on elements and then uses IDREFs
> to solve the cyclic reference problem. it's been delayed since it took me
> a while to find a good way to implement it.
Thanks robert - it looks great.
> i should probably say something about the changes to
> org.apache.commons.betwixt.io.BeanWriter since they are quite extensive.
i'
> ve tried to separate the actual writing from the logic concerning
> processing the descriptors . the writing code should now live in small
> expressXXX methods and some duplication has been reduced.
Cool.
I've been musing over possible ways to make it easy for users of betwixt to
'walk' the XML tree for a certain bean. Maybe once there's a few different
ways of outputting a bean, text, SAX & DOM (*) then we could maybe refactor
the code to make it easier & share code. Just thinking aloud here...
(*) if we had a DOM implementation based on betwixt then we could do XSLT on
beans which would be kinda cool. The domify project at SF does pretty much
the same thing though it doesn't support customizable mappings of beans to
XML. Also its easy to pipe DOM (or SAX) to other models like dom4j and JDOM.
> it's hard to write good unit test code for betwixt
Agreed - it might be worth trying out xmlunit or something for testing...
> and so i may have
> introduced new bugs. any bug reports will be gratefully received.
Things look OK so far :)
James
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[Betwixt] ID-IDREF solution to cyclic reference problem
Posted by robert burrell donkin <ro...@mac.com>.
i've just committed code that stamps IDs on elements and then uses IDREFs
to solve the cyclic reference problem. it's been delayed since it took me
a while to find a good way to implement it.
i should probably say something about the changes to
org.apache.commons.betwixt.io.BeanWriter since they are quite extensive. i'
ve tried to separate the actual writing from the logic concerning
processing the descriptors . the writing code should now live in small
expressXXX methods and some duplication has been reduced.
it's hard to write good unit test code for betwixt and so i may have
introduced new bugs. any bug reports will be gratefully received.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AltRMI] multiplexing over single connection
Posted by Paul Hammant <Pa...@yahoo.com>.
Vinay,
>Paul,
>So would the right place to export an Object
>from an API standpoint be :
>
>AltrmiFactory.exposeObject(Object o);
>
You mean in the context of BEEP and the layer it represents inside AltRMI ?
I don't quite understand what you are asking here....
AltrmiFactory is a client-side class, you would not call anythin on it
to publish (exposeObject is publishig right?).
BEEP would be used to allow us to have listeners straddling two VMs.
Consider the well understood PropertyChangeListener.
Server side :
interface XyzService {
void addListener(PropertyChangeListener pcl);
}
Client side :
class MyClient implements PropertyChangeListener {
XyzService xyzService;
public MyClient() {
xyzService = lookup(".... // via AltRMI
xyzService.addListener(this);
}
public void propertyChange(PropertyChangeEvent evt) {
System.out.println("Server has performed callback - " + evt.toString());
}
}
What we see there is the client reaching out to the server as usual
(lookup), but then registering itself as a suitable listener.
Completely asynchronously, the server can call the applicable method on
the client, even if there is TCP/IP in the way. We need at least two
channels open to do this. One (as we have now) to allow the client to
invoke methods on the server and the second to allow async invokation of
methods on the client from the server.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AltRMI] multiplexing over single connection
Posted by vinaysahil chandran <sa...@yahoo.com>.
Paul,
So would the right place to export an Object
from an API standpoint be :
AltrmiFactory.exposeObject(Object o);
?
Regards,
Vinay
--- Paul Hammant <Pa...@yahoo.com> wrote:
> 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 <Pa...@yahoo.com> 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:
>
>><ma...@jakarta.apache.org>
> >>For additional commands, e-mail:
> >><ma...@jakarta.apache.org>
> >>
> >
> >
> >__________________________________________________
> >Do You Yahoo!?
> >Yahoo! Sports - Coverage of the 2002 Olympic Games
> >http://sports.yahoo.com
> >
> >--
> >To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> >For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
> >
>
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AltRMI] multiplexing over single connection
Posted by Paul Hammant <Pa...@yahoo.com>.
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 <Pa...@yahoo.com> 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:
>><ma...@jakarta.apache.org>
>>For additional commands, e-mail:
>><ma...@jakarta.apache.org>
>>
>
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Sports - Coverage of the 2002 Olympic Games
>http://sports.yahoo.com
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [AltRMI] multiplexing over single connection
Posted by vinaysahil chandran <sa...@yahoo.com>.
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 <Pa...@yahoo.com> 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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>