Tunneling

Handling the general case of making two different networks interwork is exceedingly difficult. However, there is a common special case that is manageable. This case is where the source and destination hosts are on the same type of network, but there is a different network in between. As an example, think of an international bank with a TCP/IP-based Ethernet in Paris, a TCP/IP-based Ethernet in London, and a non-IP wide area network (e.g., ATM) in between, as shown in Fig. given below

Tunneling a packet from Paris to London.













The solution to this problem is a technique called tunneling. To send an IP packet to host 2, host 1 constructs the packet containing the IP address of host 2, inserts it into an Ethernet frame addressed to the Paris multiprotocol router, and puts it on the Ethernet. When the multiprotocol router gets the frame, it removes the IP packet, inserts it in the payload field of the WAN network layer packet, and addresses the latter to the WAN address of the London multiprotocol router. When it gets there, the London router removes the IP packet and sends it to host 2 inside an Ethernet frame.
The WAN can be seen as a big tunnel extending from one multiprotocol router to the other. The IP packet just travels from one end of the tunnel to the other, snug in its nice box. It does not have to worry about dealing with the WAN at all. Neither do the hosts on either Ethernet. Only the multiprotocol router has to understand IP and WAN packets. In effect, the entire distance from the middle of one multiprotocol router to the middle of the other acts like a serial line.
An analogy may make tunneling clearer. Consider a person driving her car from Paris to London. Within France, the car moves under its own power, but when it hits the English Channel, it is loaded into a high-speed train and transported to England through the Chunnel (cars are not permitted to drive through the Chunnel). Effectively, the car is being carried as freight, as depicted in Fig. given below. At the far end, the car is let loose on the English roads and once again continues to move under its own power. Tunneling of packets through a foreign network works the same way.


Tunneling a car from France to England.











(Courtesy:-A.S.Tanenbaum)

Asynchronous Transfer Mode(ATM)

Introduction:-
ATM is a cell-switching and multiplexing technology that combines the benefits of circuit switching (guaranteed capacity and constant transmission delay) with those of packet switching (flexibility and efficiency for intermittent traffic). It provides scalable bandwidth from a few megabits per second (Mbps) to many gigabits per second (Gbps). Because of its asynchronous nature, ATM is more efficient than synchronous technologies, such as time-division multiplexing (T.D.M.). With TDM, each user is assigned to a time slot, and no other station can send in that time slot. If a station has a lot of data to send, it can send only when its time slot comes up, even if all other time slots are empty. If, however, a station has nothing to transmit when its time slot comes up, the time slot is sent empty and is wasted. Because ATM is asynchronous, time slots are available on demand with information identifying the source of the transmission contained in the header of each ATM cell.

Evolution:-
Asynchronous transfer mode has not been on the market for a long time in comparison to other technologies . How ever credit is due to researchers of bell laboratories for their work in this this area long before it came to forefront of the media attention in late 1980's. ATM actually began to take shape in the late 1980's and the driving force behind the development was a need for a fast switching technology that supports data ,voice, video and multimedia in general.Now various types of ATM implementation can be done

Architecture
We can consider in ATM architecture following 3 points :-
1)ATM virtual connection
2)Cell Structure
3)ATM Reference Model

ATM Virtual Connections
ATM networks are fundamentally connection oriented, which means that a virtual channel (VC) must be set up across the ATM network prior to any data transfer. (A virtual channel is roughly equivalent to a virtual circuit.)
Two types of ATM connections exist: virtual paths, which are identified by virtual path identifiers, and virtual channels, which are identified by the combination of a VPI and a virtual channel identifier (VCI).
A virtual path is a bundle of virtual channels, all of which are switched transparently across the ATM network on the basis of the common VPI. All VCIs and VPIs, however, have only local significance across a particular link and are remapped, as appropriate, at each switch.
A transmission path is a bundle of VPs as shown below:







CELL Architecture
ATM is based on the switching of 53-byte cells, in which each cell consists of a 5-byte header and a payload of 48 bytes of information. Figure 14.1 illustrates the format of the ATM cell, including the explosion of its 5-byte header to indicate the fields carried in the header.



















Figure : The 53-byte ATM cell.
The 4-bit Generic Flow Control (GFC) field is used as a mechanism to regulate the flow of traffic in an ATM network between the network and the user. The use of this field is currently under development. As we will shortly note, ATM supports two major types of interfaces: Network-to-User (UNI) and Network-to-Network (NNI). When a cell flows from the user to the network or from the network to the user, it will carry a GFC bit value. However, when it flows within a network or between networks, the GFC field is not used. Instead of being wasted, its space can be used to expand the length of the Virtual Path Identifier field.
The 8-bit Virtual Path Identifier (VPI) field represents one half of a two-part connection identifier used by ATM. This field identifies a virtual path that can represent a group of virtual circuits transported along the same route. Although the VPI is eight bits long in a UNI cell, the field expands to 12-bit positions to fill the Generic Flow Control field in an NNI cell. It is described in more detail later in this chapter.
The Virtual Channel Identifier (VCI) is the second half of the two-part connection identifier carried in the ATM header. The 16-bit VCI field identifies a connection between two ATM stations communicating with one another for a specific type of application. Multiple virtual channels (VCs) can be transported within one virtual path. For example, one VC could be used to transport a disk backup operation, while a second VC is used to transport a TCP/IP-based application. The virtual channel represents a one-way cell transport facility. Thus, for each of the previously described operations, another series of VCIs is established from the opposite direction. You can view a virtual channel as an individual one-way end-to-end circuit, whereas a virtual path that can represent a collection of virtual channels can be viewed as a network trunk line. After data is within an ATM network, the VPI is used to route a common group of virtual channels between switches by enabling ATM switches to simply examine the value of the VPI. Later in this chapter, you will examine the use of the VCI.
The Payload Type Identifier (PTI) field indicates the type of information carried in the 48-byte data portion of the ATM cell. Currently, this 3-bit field indicates whether payload data represents management information or user data. Additional PTI field designators have been reserved for future use.
The 1-bit Cell Loss Priority (CLP) field indicates the relative importance of the cell. If this field bit is set to 1, the cell can be discarded by a switch experiencing congestion. If the cell cannot be discarded, the CLP field bit is set to 0.
The last field in the ATM cell header is the 8-bit Header Error Control field. This field represents the result of an 8-bit Cyclic Redundancy Check (CRC) code, computed only over the ATM cell header. This field provides the capability for detecting all single-bit errors and certain multiple-bit errors that occur in the 40-bit ATM cell header.

The ATM Protocol Reference Model
Three layers in the ATM architecture form the basis for the ATM Protocol Reference model, illustrated in Figure 14.5. Those layers are the Physical layer, the ATM layer, and the ATM Adaptation layer.









Figure : The ATM protocol suite.
The Physical Layer
As indicated in Figure 14.5, the lowest layer in the ATM protocol is the Physical layer. This layer describes the physical transmission of information through an ATM network. It is not actually defined with respect to this new technology. The absence of a Physical layer definition results from the design goal of ATM to operate on various physical interfaces or media types. Thus, instead of defining a specific Physical layer, ATM depends on the Physical layers defined in other networking protocols. Types of physical media specified for ATM include shielded and unshielded twisted-pair, coaxial cable, and fiber-optic cable, which provide cell transport capabilities ranging from a T1 rate of 1.544Mbps to a SONET range of 622Mbps.
The ATM Layer
The ATM layer represents the physical interface between the ATM Adaptation layer (AAL) and the Physical layer. Thus, the ATM layer is responsible for relaying cells from the AAL to the Physical layer for transmission, and in the opposite direction from the Physical layer to the AAL for use in an endpoint. When transporting cells to the Physical layer, the ATM layer is responsible for generating the five-byte cell header for each cell. When receiving cells from the Physical layer, the ATM layer performs a reverse operation, extracting the five-byte header from each cell.
The actual manner by which the ATM layer performs its relaying function depends on the location of the layer at a switch or at an endpoint. If the ATM layer is located in an endpoint, it receives a stream of cells from the Physical layer and transmits either cells with new data or empty cells if there is no data to send to the AAL. When located in a switch, the ATM layer is responsible for determining where incoming cells are routed and for multiplexing cells by placing cells from individual connections into a single-cell stream.
The ATM Adaptation Layer
The ATM Adaptation layer (AAL) represents the top layer in the ATM Protocol model. This layer is responsible for providing an interface between higher-layer protocols and the ATM layer. Because this interface normally occurs based on a voice, data, or video application accessing an ATM network, the operations performed by the AAL occur at endpoints and not at ATM switches. Thus, the AAL is shown in Figure 14.5 to reside at ATM endpoints.

ATM services in Market
When purchasing ATM service, you generally have a choice of four different types of service:
constant bit rate (CBR): specifies a fixed bit rate so that data is sent in a steady stream. This is analogous to a leased line.
variable bit rate (VBR): provides a specified throughput capacity but data is not sent evenly. This is a popular choice for voice and videoconferencing data.
available bit rate (ABR): provides a guaranteed minimum capacity but allows data to be bursted at higher capacities when the network is free.
unspecified bit rate (UBR): does not guarantee any throughput levels. This is used for applications, such as file transfer, that can tolerate delays.

Advantages of the ATM
ATM supports voice, video and data allowing multimedia and mixed services over a
single network.
High evolution potential, works with existing, legacy technologies
Provides the best multiple service support
Supports delay close to that of dedicated services
Supports the broadest range of burstiness, delay tolerance and loss performance through the implementation of multiple QoS classes
Provides the capability to support both connection-oriented and connectionless traffic using AALs
Able to use all common physical transmission paths like SONET.
Cable can be twisted-pair, coaxial or fiber-optic
Ability to connect LAN to WAN
Legacy LAN emulation
Efficient bandwidth use by statistical multiplexing
Scalability
Higher aggregate bandwidth
High speed Mbps and possibly Gbps

Disadvantages of the ATM
Flexible to efficiency’s expense, at present, for any one application it is usually possible to find a more optimized technology
Cost, although it will decrease with time
New customer premises hardware and software are required
Competition from other technologies -100 Mbps FDDI, 100 Mbps Ethernet and fast Ethernet
Presently the applications that can benefit from ATM such as multimedia are rare
The wait, with all the promise of ATM’s capabilities many details are still in the standards process

C++ Destructors Vs. Java finalize()

When you move from C++ to Java, one of the more subtle, yet important issues you will face is the difference between a C++ destructor and a Java finalize() method. Although similar in many respects, their actual operation is distinctively different. Let's begin by reviewing the purpose and effect of a C++ destructor and the Java finalize() method. In C++, when an object goes out of scope, it is destroyed. Just prior to its destruction, its destructor function is called (if it has one). This is a hard-and-fast rule. There are no exceptions. Let's look more closely at each part of this rule:

1. Every object is destroyed when it goes out of scope. Thus, if you declare a local object inside a function, when that function returns, that local object is automatically destroyed. The same goes for function parameters and for objects returned by functions.
2. Just before destruction, the object's destructor is called. This happens immediately, and before any other program statements will execute. Thus, a C++ destructor will always execute in a deterministic fashion. You can always know when and where a destructor will be executed.

In Java, the tight linkage of the destruction of an object and the calling of its finalize() method does not exist. In Java, objects are not explicitly destroyed when they go out of scope. Rather, an object is marked as unused when there are no longer any references pointing to it. Even then, the finalize() method will not be called until the garbage collector runs. Thus, you cannot know precisely when or where a call to finalize( ) will occur. Even if you execute a call to gc( ) (the garbage collector), there is no guarantee that finalize( ) will immediately be executed.

While the deterministic behavior of a C++ constructor and the somewhat probabilistic aspect of finalization are of little concern in most cases, they will have an impact on others. For example, consider the following C++ program:

// This C++ program can call f() indefinitely.

#include <iostream>

#include <cstdlib>

using namespace std;

const int MAX = 5;

int count = 0;

class X {

public:

// constructor


X() {

if(count<MAX) {

count++;

}

else {

cout << "Error — can't construct";

exit(1);

}

}

// destructor

~X() {

count—;

}

};

void f()

{

X ob; // allocate an object

// destruct on way out

}

int main()
{

int i;

for(i=0; i < (MAX*2); i++) {

f();

cout << "Current count is: " << count

<< endl;

}

return 0;

}

Here is the output generated by this program:

Current count is: 0

Current count is: 0

Current count is: 0

Current count is: 0

Current count is: 0

Current count is: 0

Current count is: 0

Current count is: 0

Current count is: 0

Current count is: 0

Look carefully at the constructor and destructor for X. The constructor increments the value of count as long as count is less than MAX. The destructor decrements count. Thus, count is incremented when an X object is created and decremented when an X object is destroyed. But no more than MAX objects can exist at any one time. However, in main( ), f( ) is called MAX*2 times without causing an error! Here is why. Inside f( ), an object of type X is created, causing count to be incremented, and then the function returns. This causes the object to immediately go out of scope and its destructor to be called, which decrements count. Thus, calling f( ) has no net effect on the value of count. This means that it can be called indefinitely. However, this is not the case when this program is converted to Java.

Here is the Java version of the preceding program:

// This Java program will fail after 5 calls to f().

class X {

static final int MAX = 5;

static int count = 0;

// constructor

X() {

if(count<MAX) {


count++;

}

else {

System.out.println("Error — can't construct");

System.exit(1);

}

}

// finalization

protected void finalize() {

count—;

}

static void f()

{

X ob = new X(); // allocate an object

// destruct on way out

}

public static void main(String args[]) {


int i;

for(i=0; i < (MAX*2); i++) {

f();

System.out.println("Current count is: " + count);

}

}

}

This program will fail after five calls to f( ), as this

output shows:

Current count is: 1

Current count is: 2

Current count is: 3

Current count is: 4

Current count is: 5

Error — can't construct

The reason the program fails is that garbage collection does not occur each time f( ) returns. Thus, finalize( ) is not invoked, and the value of count is not decremented. After five calls to the method, count reaches its maximum value and the program fails. It is important to emphasize that precisely when garbage collection occurs is implementation dependent. It is possible that for some implementation of Java, on some platform, the preceding program will function similarly to its C++ version. However, the point of the example remains: In C++, you know when and where a destructor will be called. In Java, you do not know when or where finalize( ) will be executed. Therefore, when porting code from C++ to Java, you will need to watch for instances in which the precise timing of the execution of a destructor is relied upon.

Event,Listeners and Adapters in JAVA

Event:-
An event typically signifies an action by the user, such as striking a key or clicking the mouse over a JButton component. But it can also refer to any other action performed by the user or the program. An event can be generated when the value of component's property changes or when a specified amount of time elapses.
Almost all programs must respond to commands from the user in order to be useful. Java's AWT uses event driven programming to achieve processing of user actins: one that underlies all modern window systems programming. Within the AWT, all user actions belong to an abstract set of things called events. An event describes, in sufficient detail, a particular user action. Rather than the program actively collecting user-generated events, the Java run time notifies the program when an interesting event occurs. Programs that handle user interaction in this fashion are said to be event driven.

There are three parts to the event model in Java:

Event object - this is an instance of a Java class that contains the characteristics of the event. For example, if the event is generated from clicking a mouse button, the event object would contain information such as the coordinates of the mouse cursor, which button was clicked, how many times it was clicked, etc.

Dispatching class/method - this is an object, which detects that an event has occurred and is then responsible for notifying other objects of the event, passing the appropriate event object to those objects. These other objects are "listeners" for the event. Most AWT components, such as Button, List, Textfield, etc. are examples of dispatching classes.

A Button, for instance, is capable of notifying other components when it is "pushed." These classes will typically have a set of two methods that can be invoked by would-be "listeners": one to tell the class that the object wants to listen and another to tell the class that the object no longer wants to listen.

These methods are conventionally named i.e. addxxListener (to add an object as a listener) or removexxListener (to remove the object as a listener).In the case of the Button, this would be "Action" to indicate the action of pushing the button. (So the methods would be addActionListener and removeActionListener).

Listener Interface - for the dispatching to work properly, the dispatching class must be able to rely on each of its listeners to contain the method that it executes when the event occurs. This is easily accomplished in Java through the use of an Interface class. The important point is that a class, which is going to be a listener, must implement that interface

Event Objects:-
Different types of events are represented by different Java classes. The base class, from which all events inherit, is java.util.EventObject. AWT defines its own base class for GUI events, java.awt.AWTEvent, which is subclassed from EventObject. AWT then defines a number of subclasses of AWTEvent in the package java.awt.event. Swing uses many of these event types and also defines more of its own in the javax.swing.event package. Some Swing events subclass AWT events, but many subclass java.util.EventObject directly. There is one other kind of event used by Swing components: the java.beans.PropertyChangeEvent, which is part of the JavaBeans component model.

The base EventObject class defines a getSource() method that returns the object that generated or triggered the event. AWTEvent defines the getID() method; the value returned by this method is used to distinguish the various types of events that are represented by the same event class. For example, FocusEvent has two possible types: FocusEvent.FOCUS_GAINED and FocusEvent.FOCUS_LOST.

In addition to these getSource() and getID() methods, the various event subclasses define methods to return whatever data values are pertinent to the particular event type. For example, MouseEvent has getX(), getY(), and getClickCount() methods; it also inherits the getModifiers() and getWhen() methods, among others, from its superclass InputEvent. Thus, when the user clicks the mouse, you receive a MouseEvent that specifies where, when, and how many times the user clicked, along with other information, such as the set of keyboard modifier keys that were held down at the time.

Event Listeners:-
An object that would like to be notified of and respond to an event is an event listener. An object that generates a particular kind of event, called an event source, maintains a list of listeners that are interested in being notified when that kind of event occurs. The event source provides methods that allow listeners to add and remove themselves from this list of interested objects. When the event source generates an event (or when a user input event such as a mouse click or a key press occurs on the event source object), the event source notifies all the listener objects that the event has occurred.

All AWT and Swing components are event sources, and all of them define (or inherit) methods for adding and removing event listeners. By convention, these methods have names that begin with "add" or "remove" and end with "Listener". So, for example, the JButton class inherits the addActionListener() and removeActionListener() methods. In the reference section of this book, you'll notice that the event registration methods of a component are grouped separately, just as the property accessor methods are. This is because one of the most important things you need to know about a component is the list of event types that it can generate.

Each type of event object typically has a corresponding event listener type. The ActionEvent event type has an ActionListener listener type, for example. Event listeners, such as ActionListener, are interfaces that extend java.util.EventListener. EventListener doesn't define any methods; it is merely a marker interface that gives all event listeners a common type. An event listener interface defines one or more methods that an event source may invoke when a particular type of event occurs. Such a method always takes an event object as its single argument. For example, the ActionListener interface defines a single method, actionPerformed(). When the user clicks on a JButton component, an ActionEvent representing that click is created and passed to the actionPerformed() method of each ActionListener object that was registered on the JButton with the addActionListener() method.

An event listener interface may define more than one method. For example, MouseListener defines several methods that correspond to different types of mouse events, including button press events and button release events. This is because MouseEvent represents several different types of mouse events. By convention, each method of an event listener is passed a single argument that is an event object of the type that corresponds to the listener. Thus, a MouseEvent object is always created when a mouse event occurs, but the object is passed to a different listener method depending on the type of mouse event that occurred.

Event Adapters:-
When an event listener interface defines more than one method, it is often accompanied by an event adapter class that provides empty implementations for each of the methods. For example, the MouseListener interface defines five different methods. If your program is interested only in the mouseClicked() method, it may be easier for you to subclass the MouseAdapter class and override mouseClicked() than to implement all five methods of the MouseListener interface directly.

What is Java applet

An applet is a program written in the Java programming language that can be included in an HTML page, much in the same way an image is included in a page. When you use a Java technology-enabled browser to view a page that contains an applet, the applet's code is transferred to your system and executed by the browser's Java Virtual Machine (JVM). For information and examples on how to include an applet in an HTML page, refer to this description of the <APPLET> tag.



Overview:
Applets are used to provide interactive features to web applications that cannot be provided by HTML alone. They can capture mouse input and also have controls like buttons or check boxes. In response to the user action an applet can change the provided graphic content. This makes applets well suitable for demonstration, visualization and teaching. There are online applet collections for studying various subjects, from physics to heart physiology. Applets are also used to create online game collections that allow players to compete against live opponents in real-time.
An applet can also be a text area only, providing, for instance, a cross platform command-line interface to some remote system. If needed, an applet can leave the dedicated area and run as a separate window. However, applets have very little control over web page content outside the applet dedicated area, so they are less useful for improving the site appearance in general (while applets like news tickers or WYSIWYG editors are also known). Applets can also play media in formats that are not natively supported by the browser
HTML pages may embed parameters that are passed to the applet. Hence the same applet may appear differently depending on the parameters that were passed.
As applets have been available before CSS, they were also widely used for trivial effects like navigation buttons. This use is criticized and declining.

Technical information:
Java applets are executed in a sandbox by most web browsers, preventing them from accessing local data like clipboard or file system. The code of the applet is downloaded from a web server and the browser either embeds the applet into a web page or opens a new window showing the applet's user interface.
A Java applet extends the class java.applet.Applet, or in the case of a Swing applet, javax.swing.JApplet. The class must override methods from the applet class to set up a user interface inside itself (Applet is a descendant of Panel which is a descendant of Container. As applet inherits from container, it has largely the same user interface possibilities as an ordinary Java application, including regions with user specific visualization.
The first implementations involved downloading an applet class by class. While classes are small files, there are frequently a lot of them, so applets got a reputation as slow loading components. However, since jars were introduced, an applet is usually delivered as a single file that has a size of the bigger image (hundreds of kilobytes to several megabytes).
The domain from where the applet executable has been downloaded is the only domain to which the usual (unsigned) applet is allowed to communicate. This domain can be different from the domain where the surrounding HTML document is hosted.
Java system libraries and runtimes are backwards compatible, allowing to write code that runs both on current and on future versions of the Java virtual machine.

Similar technologies:
Many Java developers, blogs and magazines are recommending that the Java Web Start technology be used in place of Applets.
A Java Servlet is sometimes informally compared to be "like" a server-side applet, but it is different in its language, functions, and in each of the characteristics described here about applets.

Embedding into web page:
The applet can be displayed on the web page by making use of the deprecated applet HTML element, or the recommended object element. A non standard embed element can be used with Mozilla family browsers. This specifies the applet's source and location. Object and embed tags can also download and install Java virtual machine (if required) or at least lead to the plugin page. Applet and object tags also support loading of the serialized applets that start in some particular (rather than initial) state. Tags also specify the message that shows up in place of the applet if the browser cannot run it due any reason.
However, despite object being officially a recommended tag, as of 2010, the support of the object tag was not yet consistent among browsers and Sun kept recommending the older applet tag for deploying in multibrowser environments, as it remained the only tag consistently supported by the most popular browsers. To support multiple browsers, the object tag currently requires JavaScript (that recognizes the browser and adjusts the tag), usage of additional browser-specific tags or delivering adapted output from the server side. Deprecating applet tag has been criticised. Oracle now provides a maintained JavaScript code to launch applets with cross platform workarounds.

Advantages:
A Java applet can have any or all of the following advantages:

• It is simple to make it work on Linux, Microsoft Windows and Mac OS X i.e. to make it cross platform. Applets are supported by most web browsers.
• The same applet can work on "all" installed versions of Java at the same time, rather than just the latest plug-in version only. However, if an applet requires a later version of the Java Runtime Environment (JRE) the client will be forced to wait during the large download.
• Most web browsers cache applets, so will be quick to load when returning to a web page. Applets also improve with use: after a first applet is run, the JVM is already running and starts quickly (the JVM will need to restart each time the browser starts afresh).
• It can move the work from the server to the client, making a web solution more scalable with the number of users/clients.
• If a standalone program (like Google Earth) talks to a web server, that server normally needs to support all prior versions for users which have not kept their client software updated. In contrast, a properly configured browser loads (and caches) the latest applet version, so there is no need to support legacy versions.
• The applet naturally supports the changing user state, such as figure positions on the chessboard.
• Developers can develop and debug an applet direct simply by creating a main routine (either in the applet's class or in a separate class) and calling init() and start() on the applet, thus allowing for development in their favorite Java SE development environment. All one has to do after that is re-test the applet in the AppletViewer program or a web browser to ensure it conforms to security restrictions.
• An untrusted applet has no access to the local machine and can only access the server it came from. This makes such an applet much safer to run than a standalone executable that it could replace. However, a signed applet can have full access to the machine it is running on if the user agrees.
• Java applets are fast - and can even have similar performance to native installed software.

Disadvantages:
A Java applet may have any of the following disadvantages:

• It requires the Java plug-in.
• Some organizations only allow software installed by the administrators. As a result, some users can only view applets that are important enough to justify contacting the administrator to request installation of the Java plug-in.
• As with any client-side scripting, security restrictions may make it difficult or even impossible for an untrusted applet to achieve the desired goals.
• Some applets require a specific JRE. This is discouraged.
• If an applet requires a newer JRE than available on the system, or a specific JRE, the user running it the first time will need to wait for the large JRE download to complete.
• Java automatic installation or update may fail if a proxy server is used to access the web. This makes applets with specific requirements impossible to run unless Java is manually updated. The Java automatic updater that is part of a Java installation also may be complex to configure if it must work through a proxy.
• Unlike the older applet tag, the object tag needs workarounds to write a cross-browser HTML document.

(Courtesy: wikipedia.com)

How To Block Websites In Ubuntu (Linux)

1) Open the Terminal app found in the Accessories folder in the "Applications" menu.



2) Type

sudo gedit /etc/hosts

in the prompt that appears

3)Terminal ask for your password , and after entering password a text editor will display



4) Add a line under the "127.0.0.1" line that reads "0.0.0.0" followed by the website you want to block.

5) Click the "Save" button, then restart your computer to make the changes take effect.

Running a Java Program from Command Prompt

• Create a temporary folder C:\mywork. Using Notepad or another text editor, create a small Java file HelloWorld.java with the following text:

  public class HelloWorld
  {
  public static void main(String[] args)
  {
  System.out.println("Hello, World!");
  }
  }
  

• Save your file as HelloWorld.java in C:\mywork. To make sure your file name is HeloWorld.java, (not HelloWorld.java.txt), first choose "Save as file type:" All files, then type in the file name HelloWorld.java.
  
  

• Run Command Prompt (found under All Programs/Accessories in the Start menu). Type

  C:\> cd \mywork

  This makes C:\mywork the current directory.

  C:\mywork> dir

  This displays the directory contents. You should see HelloWorld.java among the files.

  C:\mywork> set path=%path%;C:\Program Files\Java\jdk1.5.0_09\bin

  This tells the system where to find JDK programs.

  C:\mywork> javac HelloWorld.java

  This runs javac.exe, the compiler. You should see nothing but the next system prompt...

  C:\mywork> dir

  javac has created the HelloWorld.class file. You should see HelloWorld.java and HelloWorld.class among the files.

  C:\mywork> java HelloWorld

  This runs the Java interpreter. You should see the program output:

  Hello, World!

  If the system cannot find javac, check the set path command. If javac runs but you get errors, check your Java text. If the program compiles but you get an exception, check the spelling and capitalization in the file name and the class name and the java HelloWorld command. Java is case-sensitive!