Rugby Question

If I'm using rugby to serve functions outside of a firewall, so that the client will not be able to see the internal IPs of the server, do I need to use rexec and sexec to remotely execute all of the functions? Or is there a way to use the standard import method. Basically what is happening is that I keep getting errors on the server that says that it can't connect to the servers internal IP. Matt

Matt, What do your server functions do? It sounds like your firewall prevents accessing the business logic here, i.e. this is a network problem. You can have a Rugby server running on one ip address when it's a dual network-card server, that's what most people would do. Then allow incoming calls only on one card, and sandwich the box between two routers and two firewalls. If you get the router and firewall configs right there should be no problem. --Maarten

They do database reads mostly. The firewall is set up to allow incoming and outgoing connections on the ports I need. For instance "r: open tcp://ip-address:8001" works. But if I do this: server: context get-rugby-service tcp://ip-address:8001 and then try something like t: server/probe-messages userid, then i get an error on the client machine (outside of the firewall) that says that it cannot connect to 10.10.1.14 which is the internal IP address of the server. But it shouldn't be trying to connect to that IP address at all, it should be trying to connect to port 8000 on the firewall's external IP which then routs it internally to the server. I'm not super knowledgable when it comes to networks, but I'm not seeing why it should be trying to access that internal IP in the first place. Thanks for any help, Matt ------------------------------------ Matt, What do your server functions do? It sounds like your firewall prevents accessing the business logic here, i.e. this is a network problem. You can have a Rugby server running on one ip address when it's a dual network-card server, that's what most people would do. Then allow incoming calls only on one card, and sandwich the box between two routers and two firewalls. If you get the router and firewall configs right there should be no problem. --Maarten

The latest version on http://www.koopgoedkoop.net/rugby.zip uses for sure the address used by the client when doing get-rugby-service. Are you using that one? --maarten

I just downloaded the latest version of Rugby, which fixes the problem. The only problem I have now is that in the old version of Rugby I could issue a statement like "useport: server/__rugby-server-address/port-id" that would return the local port that the server is using. When trying to issue this statement in the new version (4.3) I get an error that says "Invalid path value: __rugby-server-address" Is there anyway to issue a similar statement in the new version? Thanks, Matt --------------------------------------- The latest version on http://www.koopgoedkoop.net/rugby.zip uses for sure the address used by the client when doing get-rugby-service. Are you using that one? --maarten

In addition to that, I would also need to be able to lookup the incoming connection's IP address. Is there a way to do that? Matt

Hi Matt, In the version you downloaded the client inserts the ip address that is used by get-rugby-service in the code returned by the server. The server ip address is simply the one you already use (or... a read dns://host in case of a hostname). Same for the port number. HTH, Maarten Matt MacDonald wrote:

Can you elaborate a little bit? I'm sorry, I'm having a slow day. What code returned by the server? Matt ------------------------- Hi Matt, In the version you downloaded the client inserts the ip address that is used by get-rugby-service in the code returned by the server. The server ip address is simply the one you already use (or... a read dns://host in case of a hostname). Same for the port number. HTH, Maarten Matt MacDonald wrote:

Also, I am using multiple servers, so I will know what IPs they are on, but not necessarily the ports, becuase if one goes down, for instance, i need to find out which ones are still running by the port numbers.

When a server start, it generates "stub" code, code that a client can retrieve and use to connect to a service. So.... get-rugby-service receives this code (essentially a block containing function defs) and you either do them or put them in an object. Now when the stub code is received the client replaces all *http* by the ip address it just used to connect. And when you invoke a function on a get-rugby-service'd retrieved stub it connects back, etc. --Maarten

The ports are part of the URL you provide. Get-rugby-service is nothing more than a smart rexec to a running service, so those port numbers are the same as well. Ever considered adding a "ping" function that returns true (or an error if the connection is broken)? --Maarten

THanks I think that will help

OK, so I'm seeing how the stubs contain the ip-address in the http-port local variable, but how do I get that out and into a useable form? The only thing I can think of is to echo a probe of the server to a file and parse for the http-port, but I'm sure there has got to be a better way than that. Matt -------------------------------- When a server start, it generates "stub" code, code that a client can retrieve and use to connect to a service. So.... get-rugby-service receives this code (essentially a block containing function defs) and you either do them or put them in an object. Now when the stub code is received the client replaces all *http* by the ip address it just used to connect. And when you invoke a function on a get-rugby-service'd retrieved stub it connects back, etc. --Maarten

Matt, That ip address is the same as the one you use in get-rugby-service (get-rugby-service inserts it locally) so I suggest you store it when invoking get-rugby-service. --Maarten

Sorry, I had to put this problem aside for a minute. Ok Maarten, I followed your advise to keep a running list of the server ports when I connect to them, that makes sense, but I'm still not following how the server can keep track of the clients. Basically I need to do this on the server: alive: does [ client-IP: {get client IP and port from Rugby?} ] or something like that so that and then serve that function. This way the client can call that function periodically to let the server know that it is still running. I need to have the IP for security reasons so I can make sure that the client is coming from the same address every time. If you need any more specifics, let me know. Some code would really help. THanks again, Matt -------------------------------------------------------------------------------- When a server start, it generates "stub" code, code that a client can retrieve and use to connect to a service. So.... get-rugby-service receives this code (essentially a block containing function defs) and you either do them or put them in an object. Now when the stub code is received the client replaces all *http* by the ip address it just used to connect. And when you invoke a function on a get-rugby-service'd retrieved stub it connects back, etc. --Maarten

Hi Matt,

> Sorry, I had to put this problem aside for a minute. Ok Maarten, I > followed > your advise to keep a running list of the server ports when I connect

> them, that makes sense, but I'm still not following how the server can > keep > ] > or something like that so that and then serve that function. This way

> client can call that function periodically to let the server know that

> is > still running. I need to have the IP for security reasons so I can

> sure that the client is coming from the same address every time. If

> need any more specifics, let me know. Some code would really help.

What do you mean spoofing? ---------------------------------------------- Hi Matt,

>Sorry, I had to put this problem aside for a minute. Ok Maarten, I >followed >your advise to keep a running list of the server ports when I connect

>them, that makes sense, but I'm still not following how the server can >keep >] >or something like that so that and then serve that function. This way

>client can call that function periodically to let the server know that

>is >still running. I need to have the IP for security reasons so I can

>sure that the client is coming from the same address every time. If

>need any more specifics, let me know. Some code would really help.

Pretending your somebody else's ip address. Using Ip addresses is very waek, security-wise. --Maarten

Yeah, I can see the risk in that. I'm using the secure functions of Rugby now, but I also wanted to track IPs so that within a session, a user doesn't show up on multiple IP addresses. Matt ---------------------------------------------------------------- Pretending your somebody else's ip address. Using Ip addresses is very waek, security-wise. --Maarten

Maaten, I think I found a way to get the functionality that I need, but it will require me to edit Rugby a little bit. All I need to do to it is add a current-ip field to the rugby-server object and then add the line rugby-server/current-ip: item/remote-ip to the process ports function. This way I can get the calling client's IP address from within the server functions by using "cIP: rugby-server/current-ip". Do you have any problems with me making this revision? You are welcome to use it in your distribution if you would like. Matt MacDonald

I haven't got a problem with that. Send me your changes and I will include them. --Maarten

Here are the two changes, they are in the process-ports function and the hipe-serv object type I obviously have only tested these chages for my particular scenario process-ports: func [ {Processes all ports that have events.} portz [block!] {The port list} /local temp-obj ] [ repeat item portz [ either (is-server? item) [ either item/scheme = 'udp ;udp, so call our handler [ temp-obj: get-handler item temp-obj copy item ] [ init-conn-port item first item ] ] [ if item/scheme = 'tcp [ rugby-server/current-ip: item/remote-ip <------NEW temp-obj: select hipe-serv/object-q item temp-obj/lastaccess: now temp-obj/handler temp-obj ] ] ] hipe-serv: make object! [ ;Our list of server ports server-ports: copy [] ;Our server to handler mapping server-map: copy [] ; The list of ports we wait/all for in our main loop port-q: copy [] ; Mapping of ports to objects containg additional info object-q: copy [] ; Restricted server list restricted-server: make block! 20 ; Server restrictions? restrict: no ;The thread queue threads: copy [] current-thread: none conn-timeout: 0:0:30 current-ip: none <---------NEW max-thread-waiting: 100 Matt MacDonald