JPPF, java, parallel computing, distributed computing, grid computing, parallel, distributed, cluster, grid, cloud, open source, android, .net

The open source
grid computing

 Home   About   Features   Download   Documentation   Forums 
May 21, 2019, 08:40:53 AM *
Please login or register.

Login with username, password and session length
Advanced search  
News: New users, please read this message. Thank you!
  Home Help Search Login Register  
Pages: [1]   Go Down

Author Topic: Handling connection through a firewall  (Read 6029 times)


  • Guest
Handling connection through a firewall
« on: February 11, 2007, 12:28:47 PM »

I have some suggestions about the http tunneling or more general about the comunication between different nodes of jppf in general. I would like to focus on the (worker) node server connection at first, though I think, having a more general approach for the communication between server and client and between servers is also desirable.
Let's assume we have one server (driver) in a LAN and a (worker) node somewhere in the internet that wants to do some of the computing. The node can acces the computers in the lan using the http protocol and port 80 (firewall restrictions). We need a solution on the server side and one on the node's side.

On server side I suggest a servlet container that contains one ore more servlets that redirect requests to the actual jppf server using the normal socket communication. If the jppf server runs within the same jvm as the servlets, the appropriate methods could be called directly.

Here we have two possibilities.
Variante A: Start a seperate thread or process that communicates with the node using sockets (loopback) and that calls the server using http.
Variante B- We use some kind of communication wrapper (interface) inside the node. The implementation of that wrapper can be the original socket implementation or a http communication or some other protocol (ssl, ...).

Advantages of A:
The original code can stay untouched.

Disadvantages of A:
Performance leak because an extra socket communication has to take place on the node.
More complex source code.

Advantages of B
More Clear Source code.
Better performance.
Better liabillity of classes. Communicatoion will be encapsulated in communication classes and does not have to be considered all the time.

Disadvantages of B
The sourcecode has to be refactored in several classes.

Some ideas to the refactoring and how it could be made.
We would need to have some kind of interface (wrapper) that seperates jppf functionallity from base classes like Fortunately this interface exists already and is already in use. It is the SocketWrapper interface. Unfortunately the SocketWrapper interface is coupeled to the class. I have analysed the usage of the set- and getSocket() methods and it seems to me possible to get by without these methods. The set- and getSocket() methods from the Monitor would also have to be removed.
Of course a refactoring of that scale would have to be planned carefully and I do not suggest to do it immediately. Anyway a seperation the communication functionality seems to be very desirable.

My suggestion is based on the dependency injection pattern.


  • Administrator
  • JPPF Council Member
  • *****
  • Posts: 2250
    • JPPF Web site
Handling connection through a firewall
« Reply #1 on: February 11, 2007, 05:45:19 PM »

Hi Wolfgang, thank you very much for your input.

I just went through your scenarios, and here are my comments.
My preference goes clearly to scenario A.
It has significant advantages:
- it could handle both multiple nodes and multiple drivers. This is especially useful if you have many nodes on a network/subnetwork trying to communicate with a driver behind a firewall: you don't need to have it on every node, and if done properly, it can scale very well. I've recently refactored the entire non-blocking NIO-based communications part of the driver, so as to make it reusable for about any purpose that requires scalable and fast socket-based communications.
- it has no impact on the existing code and we could implement and deliver it much faster
- it can be developed so as allow us to extend it into a general-purpose utility to have socket-based applications communicate across proxies/firewalls (I always keep in mind the "framework" part of JPPF)
- it can be deployed as either a separate process, or embedded within a node or driver when needed

The one drawback I can see now is that it would slow down communications, as you mentioned, due to the additional socket layer. Should we be embarrassed about that? Security always comes with a cost and we need to set the expectations with our users.
It also seems that a performance impact is inevitable, no matter what design we adopt, due to the need to encapsulate the JPPF protocol within HTTP requests/responses, or am I missing something?

My comments on scenario B:
- regarding the use of setSocket() and getSocket(): I implemented (quickly, I have to say) these so as to allow a node to reload its own code without disconnecting from the driver. It is essential since the node class loader relies on a socket connection for class loading.
No doubt this can be refactored and made cleaner, but I'd rather not lose the functionality.

Also, I sent a reply to your initial email, but it seems my response didn't get through to your account. Do you have an email address that the team could use? You can use mine: lcohen (at) free (dot) fr

Thanks a lot.



  • Guest
Handling connection through a firewall
« Reply #2 on: February 14, 2007, 11:13:34 AM »

Hi Lauren.
As you I also prefer scenario A. Specially as I was inspecting the JPPF sources in more detail during the last days.

I would like to handle all the http code in a seperate project for the beginning as I also have to do some testing to learn more about JPPF. Actually I have already created that project (name: http-node) and as I use multiple computers for development I would like to check in that project to have the same status anywhere.
Please give me your OK if you also think that is a reasonable solution.

Further I would need some changes in the original code. Mainly Changes in the visibillity of methods and instance variables. I plan to chanche some private or default visibillities to protected to enable subclassing of your classes.
Concrete: NodeNioServer::getQueue() NodeNioServer.queue

Please tell me also if you find anything bad in changes like this.
It would help me a lot.


  • Administrator
  • JPPF Council Member
  • *****
  • Posts: 2250
    • JPPF Web site
Handling connection through a firewall
« Reply #3 on: February 14, 2007, 09:45:48 PM »

Hi Wolfgang,

I think we're very much on the same page. Please feel free to go ahead and create the new module/project. Can you please make sure it has the same folder structure as the others?
The changes you propose are working great for me, and please feel free to make those changes and commit them to CVS.

Pages: [1]   Go Up
JPPF Powered by SMF 2.0 RC5 | SMF © 2006–2011, Simple Machines LLC Get JPPF at Fast, secure and Free Open Source software downloads