a question about RMI

[KP Kirchdörfer]

Hi;

I know this mainly a java question, but as this group is as nice as competent,
I just ask.

What I did is to build a jar for the server side and one for the client side.
Talking to each other is done with RMI (I did the first time, and the idea
behind is just cool).

On the Server side I start the app with:

method main(args=String[]) static
        do
        LocateRegistry.createRegistry(1099)
        name = "//localhost/DBBuchung"
        dbb=DBBuchung()
        Naming.rebind(name,dbb)

The client connects with

        srv='rmi://castelnuovo.homeip.net/DBBuchung'
        db=DBbuchungI Naming.lookup(srv)

The Server has the local IP Adress 192.168.22.101 and I do have a VPN between
my LAN (192.168.10.0) and the 192.168.22.0 LAN.

That environment works well.

It does not work  if I try run without the VPN and therefor to access the
RMI-Server from the (Inter)net.

Starting the server side with
java -Djava.rmi.server.hostname=castelnuovo.homeip.net
or the IP address as rmi.server.hostname let the client stop working at
Naming.lookup(srv)

I opened the fw for the standard RMI port 1099 and see no error messages on
the fw.

Any ideas how to solve or at least to further debug the pb?

TIA
kp

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Patric Bechtel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

KP Kirchdoerfer schrieb am 30.03.2010 21:59:

> Hi;
>
> I know this mainly a java question, but as this group is as nice as competent,
> I just ask.
>
> What I did is to build a jar for the server side and one for the client side.
> Talking to each other is done with RMI (I did the first time, and the idea
> behind is just cool).
>
> On the Server side I start the app with:
>
> method main(args=String[]) static
> do
> LocateRegistry.createRegistry(1099)
> name = "//localhost/DBBuchung"
> dbb=DBBuchung()
> Naming.rebind(name,dbb)
>
> The client connects with
>
> srv='rmi://castelnuovo.homeip.net/DBBuchung'
> db=DBbuchungI Naming.lookup(srv)
>
> The Server has the local IP Adress 192.168.22.101 and I do have a VPN between
> my LAN (192.168.10.0) and the 192.168.22.0 LAN.
>
> That environment works well.
>
> It does not work  if I try run without the VPN and therefor to access the
> RMI-Server from the (Inter)net.
>
> Starting the server side with
> java -Djava.rmi.server.hostname=castelnuovo.homeip.net
> or the IP address as rmi.server.hostname let the client stop working at
> Naming.lookup(srv)
>
> I opened the fw for the standard RMI port 1099 and see no error messages on
> the fw.
>
> Any ideas how to solve or at least to further debug the pb?

Hi KP,

I had a similar problem to solve quite a few years ago. Let me tell you
ahead, that I used RMI intensively in intranets for a long time already,
but when it came to the internet and some of it's implications, I found
RMI to be quite unsuitable for that environment.
The reasons are simple:
- - RMI initiates Connections on many ports, the server tells the client
where to connect. *Very* bad idea in natted networks. The server must be
connected more or less directly to the internet...
- - authentication is futile... ;-)
- - Network latency is almost zero, especially in the internet
- - The behaviour of the gc as soon as RMI is used is, let say, _strange_.
There's some secret switches to adjust the grade of weirdness a bit, but
well, just gradually.

(point 2 and 3 should have irony tags, just in case you missed it).

All these oddities brought me to develop an own direct socket protocol,
and believe it or not, it's surprisingly simple. The main feature that
RMI uses is proxying and serialization. Proxying is what makes gc mad
and things slightly complicated, serialization is one of the coolest
things since sliced bread.
So what I suggest is, take a server socket on a port of your choice,
call accept() on it and spawn a thread with the returned socket object,
get the streams from it, encapsulate them into ObjectStreams and voilà,
you're ready with your server. The client does everything the other way ;-)

Then, you can send objects back and forth both. Don't forget to flush
the output when you're ready, otherwise, the communication can stuck
between the send and receive buffers of the TCP stacks.

At will, you can mix some TLS or compression into the mix, maybe some
pooling or whatever.

If your are stuck somewhere, feel free to ask.

hth, Patric

- --
Mit freundlichen Gruessen / Regards
Patric Bechtel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: GnuPT 2.5.2

iEYEARECAAYFAkuykowACgkQfGgGu8y7ypCjkACfdE/scp0Eq5vGZPJPNlbhFLPo
ek8AoMN4iRSfvWtToWIcWDquVvThMI4Y
=m1OU
-----END PGP SIGNATURE-----
_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[KP Kirchdörfer]

Am Mittwoch, 31. März 2010 02:08:49 schrieb Patric Bechtel:

> KP Kirchdoerfer schrieb am 30.03.2010 21:59:
> > Hi;
> >
> > I know this mainly a java question, but as this group is as nice as
> > competent, I just ask.
> >
> > What I did is to build a jar for the server side and one for the client
> > side. Talking to each other is done with RMI (I did the first time, and
> > the idea behind is just cool).
> >
> > On the Server side I start the app with:
> >
> > method main(args=String[]) static
> > do
> > LocateRegistry.createRegistry(1099)
> > name = "//localhost/DBBuchung"
> > dbb=DBBuchung()
> > Naming.rebind(name,dbb)
> >
> > The client connects with
> >
> > srv='rmi://castelnuovo.homeip.net/DBBuchung'
> > db=DBbuchungI Naming.lookup(srv)
> >
> > The Server has the local IP Adress 192.168.22.101 and I do have a VPN
> > between my LAN (192.168.10.0) and the 192.168.22.0 LAN.
> >
> > That environment works well.
> >
> > It does not work  if I try run without the VPN and therefor to access the
> > RMI-Server from the (Inter)net.
> >
> > Starting the server side with
> > java -Djava.rmi.server.hostname=castelnuovo.homeip.net
> > or the IP address as rmi.server.hostname let the client stop working at
> > Naming.lookup(srv)
> >
> > I opened the fw for the standard RMI port 1099 and see no error messages
> > on the fw.
> >
> > Any ideas how to solve or at least to further debug the pb?
>
> Hi KP,
>
> I had a similar problem to solve quite a few years ago. Let me tell you
> ahead, that I used RMI intensively in intranets for a long time already,
> but when it came to the internet and some of it's implications, I found
> RMI to be quite unsuitable for that environment.
> The reasons are simple:
> - RMI initiates Connections on many ports, the server tells the client
> where to connect. *Very* bad idea in natted networks. The server must be
> connected more or less directly to the internet...
> - authentication is futile... ;-)
> - Network latency is almost zero, especially in the internet
> - The behaviour of the gc as soon as RMI is used is, let say, _strange_.
> There's some secret switches to adjust the grade of weirdness a bit, but
> well, just gradually.
>
> (point 2 and 3 should have irony tags, just in case you missed it).
>
> All these oddities brought me to develop an own direct socket protocol,
> and believe it or not, it's surprisingly simple. The main feature that
> RMI uses is proxying and serialization. Proxying is what makes gc mad
> and things slightly complicated, serialization is one of the coolest
> things since sliced bread.
> So what I suggest is, take a server socket on a port of your choice,
> call accept() on it and spawn a thread with the returned socket object,
> get the streams from it, encapsulate them into ObjectStreams and voilà,
> you're ready with your server. The client does everything the other way ;-)
>
> Then, you can send objects back and forth both. Don't forget to flush
> the output when you're ready, otherwise, the communication can stuck
> between the send and receive buffers of the TCP stacks.
>
> At will, you can mix some TLS or compression into the mix, maybe some
> pooling or whatever.
>
> If your are stuck somewhere, feel free to ask.
>
> hth, Patric

Hi Patric;

thx for responding that quickly.

The quick and dirty solution was to set the port for the UnicastRemoteObject
in the class that extends UnicastRemoteObject with super(int).

But I got your points and think sending objects as described will be doable.
Anyway I don't get the full picture yet. What attracted me to RMI was the
_remote method invocation_ part that accepts objects as arguments or returns
objects. Any hints how I can accomplish that with my "own protocol"?

kp


_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Patric Bechtel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

KP Kirchdoerfer schrieb am 31.03.2010 09:42:

>
> Hi Patric;
>
> thx for responding that quickly.
>
> The quick and dirty solution was to set the port for the UnicastRemoteObject
> in the class that extends UnicastRemoteObject with super(int).
>
> But I got your points and think sending objects as described will be doable.
> Anyway I don't get the full picture yet. What attracted me to RMI was the
> _remote method invocation_ part that accepts objects as arguments or returns
> objects. Any hints how I can accomplish that with my "own protocol"?

Hi KP,

that's easy. Just transfer a command, which can be an object on its own
or just the parameters one by one, and send the result back to the
client. It's easy, eh? I think it's not as simple as making a method
remote callable, but it's ok.
You can also think about a reflection-based approach, which gets pushes
method names and parameters and tries to find a fitting "victim" on the
server to call. That would lower down the amount of work in case you
have plenty of functions to call.

- --
Mit freundlichen Gruessen / Regards
Patric Bechtel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: GnuPT 2.5.2

iEYEARECAAYFAkuzDO0ACgkQfGgGu8y7ypApywCgoqAXACcX4OHewDe5d3aeNwoR
ProAoJhCbOSX0/QX0JE6CGRRDMgWRon0
=o30S
-----END PGP SIGNATURE-----
_______________________________________________
Ibm-netrexx mailing list
[hidden email]