Menu
▾
▴
jboss-dev-forums
|
From: <ad...@jb...> - 2005-06-29 18:32:46
|
NAT only works if the firewall understands the protocol. You can't just embed an ip address in a tcp/ip stream and expect the firewall to automagically replace it. Things like RMI have system properties to override the hostname seen by the clients on the other side of the firewall, e.g. java.rmi.server.hostname The advantage of using the hostname is that it can be resolved to different ip addresses on different subnets based on dns configuration. The disadvantage is that you have more complicated dns configuration. In general, it is not a good idea to transport an InetAddress like UIL2 does, since it is pre-resolved on the server and it will usually prefer the ip address. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883126#3883126 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883126 |
|
From: <ad...@jb...> - 2005-06-29 18:36:03
|
JXTA looks to require running "relay" software outside the firewall. http://www.dcs.gla.ac.uk/~iraklis/fyp_report/node24.html#firewallFigure View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883128#3883128 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883128 |
|
From: <sco...@jb...> - 2005-06-29 18:55:57
|
I'm not talking about replacing a marshalled InetAddress. There simply needs to be an ability to override any connection parameters passed to the connection factory the client endpoint is using to establish its connection. When we override the uil2 settings using system properties, the marshalled InetAddress is ignored. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883132#3883132 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883132 |
|
From: <sco...@jb...> - 2005-06-29 18:59:40
|
I'm not too concerned about the jxta details which may be good or bad, just whether or not there is abstraction in the form of the client side connection setup that works with firewalls or even non-dns aware envs where the participants need to be located at runtime when the connection is to be created. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883133#3883133 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883133 |
|
From: <ad...@jb...> - 2005-06-29 19:04:07
|
Yes, I know. My point was that the system property should be unnecessary in most cases. If we didn't resolve the network address on the server and instead just allowed something to be configured/transported that might only make sense to resolve on the client. i.e. differentiate bind address == nic that the service accepts requests on (could be 0.0.0.0) connect address == host name used by client that could resolve to the firewall with port forwarding enabled or might resolve to different nics on different subnets even without a firewall. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883134#3883134 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883134 |
|
From: <sco...@jb...> - 2005-06-29 19:18:20
|
Ok, I see what your saying, but the problem is that the server may not have any meaningful name. We do have a notion of an "external" interface for the client, but it is sometimes resolved too early in our current usage, and sometimes its simply not known. If the remoting layer had a tiered approach to resolving a name that first tried to use the name as a hostname/ip address, and then a system property of even a transformed system property (e.g., given a name of host1 use system property org.jboss.remoting.address.host1) then there is the ability to handle any situation while allowing for a purely server side configuration. In the future we could even have a locator service to deal with names that may not be in dns as is the case for redevuouz, and some sip names. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883135#3883135 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883135 |
|
From: <ad...@jb...> - 2005-06-29 19:20:58
|
and "connect address" might resolve to the "relay" in the JXTA example. For DNS environments there would have to be a fallback ip address for when the hostname could not be resolved. Or you just manually configure the ip address as the "connect address". Also I think jboss-remoting has the notion of a discovery service that serves as an abstraction for resolving locators. i.e. the discovery can be anything from dynamic discovery, to preconfigured, a reference server like a DNS or a jgroups gossip service. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883137#3883137 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883137 |
|
From: <tom...@jb...> - 2005-07-01 04:27:33
|
Remoting has the ability to set the bind address and port for both the client and server for all transports (see http://wiki.jboss.org/wiki/Wiki.jsp?page=Remoting_Transports_Configuration). This is only useful if know what the NAT will use for the external address and port for the server. For a long time I have been thinking about how to detect this automatically. The problem is have to be able to either query the router(executing the NAT), which is not practical, or having something external to the network that can identify the ip/port to get back to the server externally. The later approach is fairly easy, but then have an issue of reliability. Am open to suggestions for this. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883304#3883304 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883304 |
|
From: <tom...@jb...> - 2005-07-01 04:37:53
|
BTW, this is one of the things I have talked to Eric and Ryan a little about for having setup in the QA lab for testing. Is currently a pain in the ass to test from my home network. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883306#3883306 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883306 |
|
From: <sco...@jb...> - 2005-07-01 17:38:54
|
The issue is how is the connection handled when the connection endpoint that the client needs to use is not known on the server side. It may not even be meaningful to have a name for the clientConnectAddress. If there is a name, we need a multi-step approach to resolving it at the time the client is making the connection. We can either code a multi-step behavior, or introduce an interface to externalize the resolution:
{{{
import java.net.InetSocketAddress;
public interface EndpointResolver
{
public InetSocketAddress resolve(String name, int port);
}
}}}
We could also have a resolver chain notion to tier prioritize and stack the resolution process.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883398#3883398
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883398
|
|
From: <tom...@jb...> - 2005-07-01 18:44:00
|
This is all fine. The problem is I still don't understand how anyone on the client side is going to be able to resolve how to access the server during runtime without some extra information being provided from somewhere. The only way I can see this working is if the server broadcasts some type of message that is picked up by something external to the network and resolves where it came from (and uses that routing path to get back to the server). This can be done via detection, but means the detector has to run outside the server network, which won't work for multicast and is probably not practical for JNDI. I am guessing I am missing something somewhere? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883403#3883403 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883403 |
|
From: <sco...@jb...> - 2005-07-01 18:55:50
|
Right, there is info needed, but this info is not availble on the server side. I put up a service on X, and have no control over the path the client has to navigate to get to me. Its his net admin that says to connect to service X, use endpoint Y in order to get through the firewall. The simplest way to handle this on the client is via system properties that are specified on the client command line. Adrian's point is what we should allow for more sophisticated name resolution on the client rather than having to require system properties. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883404#3883404 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883404 |
|
From: <tom...@jb...> - 2005-07-02 07:00:05
|
Ok. I understand the problem well. Remoting allows for system property settings on the client already. What I am not getting is what this "more sophisticated name resolution" would be? I am just unaware of any mechanism to do this. If there are any, would love to know what they are and will try to implement it. Know this is a serious issue for those wanting to run fat clients using remoting in unknown environments. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883438#3883438 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883438 |
|
From: <sco...@jb...> - 2005-07-03 00:09:51
|
more sophisticated name resolution: - Trying to resolve the name bound on the server as the client address as a dns name in the client. Either a client specific dns server, or even hosts file entries will be selected. - Querying a Rendezvous like server - Querying a Sipp server - Looking up the name to address binding in JNDI ... Just anything that allows for centralized management of the client side name resolution as opposed to having to enter the bindings in each client application. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883462#3883462 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883462 |
|
From: <tom...@jb...> - 2005-07-04 02:09:32
|
Ok. Thanks. JBREM-154. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3883493#3883493 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3883493 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X