On 08/15/2009 07:20 PM, Witold Szczerba wrote:
>> That's an issue with firewalls and NAT. It might cause some inconvenience in
>> some situations, but "firewalls and NAT" is not "over the Internet". It's in
>> "over the Internet to a private network that is not visible to the world".
>>
> You say that NAT is only about the Internet and private network that
> is not visible to "the world"? No, it is about traveling from one
> network (passing by one or more routers) to another network. This is
> very typical, especially when it comes to servers, which are very
> often in theirs own (DMZ or not) networks behind companies' main
> gateways.
>
Not really. I'm saying that anybody can create problems for themselves,
and NAT is one very effective may of doing this. :-)
Let's just make sure the problem is clear. The problem being referenced
isn't about "the Internet". The problem is with Glassfish on a private
network being accessed from a public network.
>> This is a problem that affects lots of applications. What does MSN do if it
>> tries to negotiate P2P between two clients that are both behind "firewalls
>> and NAT"? Neither client can directly connect to the other client, so it
>> reverts to a server-based proxy solution which is much slower.
>>
> This is totally off topic. Who says here about P2P??
>
It's only off-topic if you are reading the specifics. If you back off
for a bit - you'll see that the problem of private networks being
accessed from public networks is faced by MANY different applications.
In fact, HTTP is frequently sold as the answer to navigating such
networks, which is where the Jersey suggestion comes in.
I happened to give a P2P example. You don't care about P2P. Fine, let's
talk about something else. What about passive vs active FTP connections?
If the server calls the client back, and the client isn't accessible
because it is on a private network, FTP fails. So, the standard model
for FTP has slowly switched to the client contacting the server for the
data port instead of the other way around. Every protocol that supports
callbacks or redirects has to face this problem.
>> If you want to be able to safely navigate through NAT, you'll need to
>> restrict yourself to protocols which only connect one-way and don't send
>> callback addresses that may not be accessible. [...]
>> I don't know personally whether RMI/CORBA can be made to work through
>> firewalls and NAT. The article you posted seems to suggest it is possible,
>> but may require some tweaking to get it to work right.
>>
> This is nonsense. You think the RMI/CORBA is some kind of P2P
> protocol? No, this is "one-way", the problem is Glassfish - I have no
> idea why - puts into the response its own IP address. Maybe this is
> something about load balancing or something. Whatever reason it is -
> it has ugly side effect which should be considered a bug or a high
> priority feature to implement.
>
Never said it was P2P. Also, it seems quite clear, that it does send a
callback address, so whether you think it is nonesense or not - that's
how it works.
Should it be easy to make sure the callback address is correct? Sure!
> I agree with the author of this thread as I had same problems with
> Glassfish. Our standalone Swing application refuses to connect to
> Glassfish when it is in different network. Initially client connects
> to server, but Glassfish hard-codes its internal IP address as a
> "reply-to" and no further communication happens. We worked this around
> using VPN, so remote offices, using VPN, are (virtually) one the same
> network as the HQ. That would be huge relief if they would fix that
> issue.
No argument. :-)
It should be fixed. I just tried to direct the conversation towards the
actual problem, rather than something nebulous like "Glassfish doesn't
work over the Internet". No need to jump on me.
Cheers,
mark
--
Mark Mielke<mark_at_mielke.cc>