|
SNMP communication through applets can also be performed using HTTP protocol. Though TCP/IP connection is more efficient than HTTP, HTTP access is required when we want to talk to a network with firewall restrictions.
Need for HTTP Tunneling
A firewall is a security mechanism that protects a private network being accessed from the public domain (the internet as a whole). It is typically implemented on a gateway device and protects the internal network from unauthorized access from outside the firewall. The firewall may also be configured to restrict the client's outside access.
A firewall can be configured to restrict the types of protocols that may travel across the firewall and also the ports that these protocols access. Usually firewalls running on web servers are configured to allow only HTTP requests by enabling only the incoming requests on the default HTTP port 80 while blocking both incoming and outgoing requests on other ports. This allows the users outside the firewall to only browse web pages and access nothing else. It also blocks outside attempts inside the firewall to access the network.
Normally, a client running an applet from outside the firewall cannot connect to the server due to the firewall restrictions. However, one way of bypassing this restriction and enabling Java applets to communicate with the servers is through HTTP tunneling. This is done is by creating servlets on the Java-enabled web server that listen for the requests from the client programs. The client request messages are embedded within HTTP request format because the server allows the HTTP requests to pass through the firewall. After the servlet module receives the HTTP request from the client, it strips the HTTP header information and processes the embedded SNMP request. Then the servlet module sends the SNMP request to the agent through UDP. On getting a response from the agent, it is passed back to the applet.

If the client applet runs behind a firewall, it cannot connect to a server outside the firewall because the firewall prevents the socket connections. However, we can connect the applet to servers through HTTP.

On the client side, the following code uses the URLConnection to send data to the server.
|
//connect URL url = new URL("http://www.myserver.com/servlets/myservlet"); URLConnection conn = url.openConnection(); conn.setDoOutput(true); conn.setUseCaches(false); conn.setRequestProperty("Content-Type", "application/octet-stream"); //Open output stream and send data OutputStream out = conn.getOutputStream(); out.flush(<); out.close(); //Open input stream and read the data back InputStream in = conn.getInputStream(); in.close() |
On the server side when the client calls openConnection(), the servlet's doPost() method is called. In that method, we can read the data and write back to the client.
Limitations of Using HTTP protocol
Like most network protocols, HTTP uses the client-server model: An HTTP client opens a connection and sends a request message to an HTTP server. The server then returns a response message with the resource that was requested. After delivering the response, the server closes the connection, making HTTP a stateless protocol. Therefore, each resource to be retrieved requires its own connection. Opening and closing connections takes a substantial amount of CPU time, bandwidth, and memory.
However, HTTP 1.1 uses persistent connections by default by allowing multiple transactions to take place over a single persistent connection thus ensuring faster response. However browsers, such as Netscape 4.x and IE 4.x use HTTP 1.0 that does not use persistent connection. As a result, using HTTP from applets is a bit slower than using TCP/IP.
Tunneling support in WebNMS SNMP API
Applet support through HTTP in the WebNMS API is by means of servlets residing in the web server. HttpSnmpGWServlet is started with the web server used. The applet forwards the request to the HttpSnmpGWServlet using HTTP. HttpSnmpGWServlet uses the SNMP classes to forward and get the response from the remote device and pass it back to the applet using HTTP. Therefore, you have the option of selecting between TCP/IP and HTTP for connecting the applet and the server (SAServer in case of TCP/IP and HTTPSnmpGWServlet in case of HTTP). For selecting between these two options, you have to specify the value for the parameter PROTOCOL in the HTML file.
The changes to be made in the configuration file of the Tomcat web server to run HttpSnmpGWservlet is given in Installation Notes.
HTTP provides the following.
Ability to access SNMP data available with the devices in the network.
Mechanism to receive traps.
Ability to create/delete files and directories and save information on files, on the server.
Provides the ability to access SNMP data available with the devices in the network
When SnmpSession is opened, it instantiates SASClient for communicating with the SAS server or HttpSnmpGWServlet depending on the parameter value specified in the HTML file. The applets need to only specify the protocol value in the HTML file.
The session.open(Applet) method instantiates SASClient. The SASClient constructor, depending on the value set in the setSASProtocol() or from the parameter PROTOCOL in the HTML file, chooses the protocol it wants to communicate. The value for protocol can be either TCP_PROTOCOL (1) or HTTP_PROTOCOL (2). TCP_PROTOCOL uses TCP/IP connection and forward the SNMP request to SAS and HTTP_PROTOCOL uses HTTP and forward the request to the servlet loaded with the web server.
By default, the port value is written in SASPort.html. If the user wants the port value to be written in some other file, setPortFileName(String) method in SAServer class can be used. Alternatively, while starting the SAServer, the user can enable the option "-portfile" and specify the filename. On the client side, the tag should be given as PORT_FILE_NAME and the corresponding value as the filename given on the SAServer side. In case of SAS, a TCP connection is established between the applet and the SAS server running on the port. On the other hand, in case of HTTP, a connection using HTTP is established between the applet and the servlet loaded with the web server. This connection is used for future communication with SNMP devices.
By default, the value of the setSASProtocol() is 1. So we need to explicitly set the value to 2 to use the HTTP protocol for communication. Currently the equivalent of setSASProtocol() is not available for Beans components. Therefore, if the applets developed using Beans components need to use HTTP protocol for communication, we need to specify the value for the parameter PROTOCOL in the HTML file.
After setting the protocol to HTTP, the communication to SNMP devices can be done in similar way as we discussed in Support Through SAS.
Provides a mechanism to receive traps
If applets wish to receive traps, they have to register with the SASClient. It is similar to receiving traps using SAS. Refer Support Through SAS.
Provides ability to create/delete files and directories and save information on files, on the server
Using HTTP, applets can perform operations on directories and files in the HTTPUsers directory available in the httpdemo directory. The methods for performing these operations are same as those in SAS. The following the file-related operations using HTTP.
|
appendFile(String filename,byte[ ] data) createDir(String directory) deleteDir(String directory) deleteFile(String filename) saveFile(String filename,byte[ ] data) |
Limitations
Sending and receiving application-specific data, executing custom Java classes on the server and getting the results, and resolving between internet hostnames and addresses using HTTP protocol are not supported with the current release.
Currently, the servlet used for communicating with the applet is loaded using the Tomcat web server which is packaged with the WebNMS SNMP API. Details of configuring it with other web servers, such as Apache will be provided in the next release.
By default, browsers such as Netscape and IE use HTTP 1.0 that does not use persistent connection. As a result, using HTTP protocol from applets is a bit slower than using the TCP/IP.
|