A network socket is an endpoint of an inter-process communication flow across a computer

network. Today, most communication between computers is based on the Internet Protocol;
therefore most network sockets are Internet sockets.
A socket API is an application programming interface (API), usually provided by the operating
system, that allows application programs to control and use network sockets. Internet socket
APIs are usually based on the Berkeley sockets standard.
A socket address is the combination of an IP address and a port number, much like one end of a
telephone connection is the combination of a phone number and a particular extension. Based on
this address, internet sockets deliver incoming data packets to the appropriate application process
or thread.
The Transmission Control Protocol (TCP) is one of the core protocols of the Internet protocol
suite (IP), and is so common that the entire suite is often called TCP/IP. TCP provides reliable,
ordered and error-checked delivery of a stream of octets between programs running on
computers connected to a local area network, intranet or the public Internet. It resides at the
transport layer.
Web browsers use TCP when they connect to servers on the World Wide Web, and it is used to
deliver email and transfer files from one location to another. HTTP, HTTPS, SMTP, POP3,
IMAP, SSH, FTP, Telnet and a variety of other protocols are typically encapsulated in TCP.
Applications that do not require the reliability of a TCP connection may instead use the
connectionless User Datagram Protocol (UDP), which emphasizes low-overhead operation and
reduced latency rather than error checking and delivery validation.
The User Datagram Protocol (UDP) is one of the core members of the Internet protocol suite
(the set of network protocols used for the Internet). With UDP, computer applications can send
messages, in this case referred to as datagrams, to other hosts on an Internet Protocol (IP)
network without prior communications to set up special transmission channels or data paths. The
protocol was designed by David P. Reed in 1980 and formally defined in RFC 768.
UDP uses a simple transmission model with a minimum of protocol mechanism.
[1]
It has no
handshaking dialogues, and thus exposes any unreliability of the underlying network protocol to
the user's program. As this is normally IP over unreliable media, there is no guarantee of
delivery, ordering, or duplicate protection. UDP provides checksums for data integrity, and port
numbers for addressing different functions at the source and destination of the datagram.
UDP is suitable for purposes where error checking and correction is either not necessary or is
performed in the application, avoiding the overhead of such processing at the network interface
level. Time-sensitive applications often use UDP because dropping packets is preferable to
waiting for delayed packets, which may not be an option in a real-time system.
[2]
If error
correction facilities are needed at the network interface level, an application may use the
Transmission Control Protocol (TCP) or Stream Control Transmission Protocol (SCTP) which
are designed for this purpose.
A number of UDP's attributes make it especially suited for certain applications.
It is transaction-oriented, suitable for simple query-response protocols such as the
Domain Name System or the Network Time Protocol.
It provides datagrams, suitable for modeling other protocols such as in IP tunneling or
Remote Procedure Call and the Network File System.
It is simple, suitable for bootstrapping or other purposes without a full protocol stack,
such as the DHCP and Trivial File Transfer Protocol.
It is stateless, suitable for very large numbers of clients, such as in streaming media
applications for example IPTV
The lack of retransmission delays makes it suitable for real-time applications such as
Voice over IP, online games, and many protocols built on top of the Real Time Streaming
Protocol.
Works well in unidirectional communication, suitable for broadcast information such as
in many kinds of service discovery and shared information such as broadcast time or
Routing Information Protocol
The term network programming refers to writing programs that execute across multiple devices
(computers), in which the devices are all connected to each other using a network.
The java.net package of the J2SE APIs contains a collection of classes and interfaces that
provide the low-level communication details, allowing you to write programs that focus on
solving the problem at hand.
The java.net package provides support for the two common network protocols:
TCP: TCP stands for Transmission Control Protocol, which allows for reliable
communication between two applications. TCP is typically used over the Internet
Protocol, which is referred to as TCP/IP.
UDP: UDP stands for User Datagram Protocol, a connection-less protocol that allows for
packets of data to be transmitted between applications.
This tutorial gives good understanding on the following two subjects:
Socket Programming: This is most widely used concept in Networking and it has been
explained in very detail.
URL Processing: This would be covered separately. Click here to learn about URL
Processing in Java language.
Socket Programming:
Sockets provide the communication mechanism between two computers using TCP. A client
program creates a socket on its end of the communication and attempts to connect that socket to
a server.
When the connection is made, the server creates a socket object on its end of the communication.
The client and server can now communicate by writing to and reading from the socket.
The java.net.Socket class represents a socket, and the java.net.ServerSocket class provides a
mechanism for the server program to listen for clients and establish connections with them.
The following steps occur when establishing a TCP connection between two computers using
sockets:
The server instantiates a ServerSocket object, denoting which port number
communication is to occur on.
The server invokes the accept() method of the ServerSocket class. This method waits
until a client connects to the server on the given port.
After the server is waiting, a client instantiates a Socket object, specifying the server
name and port number to connect to.
The constructor of the Socket class attempts to connect the client to the specified server
and port number. If communication is established, the client now has a Socket object
capable of communicating with the server.
On the server side, the accept() method returns a reference to a new socket on the server
that is connected to the client's socket.
After the connections are established, communication can occur using I/O streams. Each socket
has both an OutputStream and an InputStream. The client's OutputStream is connected to the
server's InputStream, and the client's InputStream is connected to the server's OutputStream.
TCP is a twoway communication protocol, so data can be sent across both streams at the same
time. There are following usefull classes providing complete set of methods to implement
sockets.
ServerSocket Class Methods:
The java.net.ServerSocket class is used by server applications to obtain a port and listen for
client requests
The ServerSocket class has four constructors:
SN Methods with Description
1
public ServerSocket(int port) throws IOException
Attempts to create a server socket bound to the specified port. An exception occurs if the port
is already bound by another application.
2
public ServerSocket(int port, int backlog) throws IOException
Similar to the previous constructor, the backlog parameter specifies how many incoming
clients to store in a wait queue.
3
public ServerSocket(int port, int backlog, InetAddress address) throws IOException
Similar to the previous constructor, the InetAddress parameter specifies the local IP address
to bind to. The InetAddress is used for servers that may have multiple IP addresses, allowing
the server to specify which of its IP addresses to accept client requests on
4
public ServerSocket() throws IOException
Creates an unbound server socket. When using this constructor, use the bind() method when
you are ready to bind the server socket
UDP vs. TCP
UDP works a bit differently from TCP. When you send data via TCP you first create a
connection. Once the TCP connection is established TCP guarantess that your data arrives at the
other end, or it will tell you that an error occurred.
With UDP you just send packets of data (datagrams) to some IP address on the network. You
have no guarantee that the data will arrive. You also have no guarantee about the order which
UDP packets arrive in at the receiver. This means that UDP has less protocol overhead (no
stream integrity checking) than TCP.
UDP is appropriate for data transfers where it doesn't matter if a packet is lost in transition. For
instance, imagine a transfer of a live TV-signal over the internet. You want the signal to arrive at
the clients as close to live as possible. Therefore, if a frame or two are lost, you don't really care.
You don't want the live broadcast to be delayed just to make sure all frames are shown at the
client. You'd rather skip the missed frames, and move directly to the newest frames at all times.
This could also be the case with a surveillance camera broadcasting over the internet. Who cares
what happened in the past, when you are trying to monitor the present. You don't want to end up
being 30 seconds behind reality, just because you want to show all frames to the person
monitoring the camera. It is a bit different with the storage of the camera recordings. You may
not want to lose a single frame when recording the images from the camera to disk. You may
rather want a little delay, than not have those frames to go back and examine, if something
important occurs.
RMI (Remote Method Invocation) is a way that a programmer, using the Java programming
language and development environment, can write object-oriented programming in which
objects on different computers can interact in a distributed network. RMI is the Java version of
what is generally known as a remote procedure call (RPC), but with the ability to pass one or
more objects along with the request. The object can include information that will change the
service that is performed in the remote computer. Sun Microsystems, the inventors of Java, calls
this "moving behavior." For example, when a user at a remote computer fills out an expense
account, the Java program interacting with the user could communicate, using RMI, with a Java
program in another computer that always had the latest policy about expense reporting. In reply,
that program would send back an object and associated method information that would enable
the remote computer program to screen the user's expense account data in a way that was
consistent with the latest policy. The user and the company both would save time by catching
mistakes early. Whenever the company policy changed, it would require a change to a program
in only one computer.
Sun calls its object parameter-passing mechanism object serialization. An RMI request is a
request to invoke the method of a remote object. The request has the same syntax as a request to
invoke an object method in the same (local) computer. In general, RMI is designed to preserve
the object model and its advantages across a network.
RMI is implemented as three layers:
A stub program in the client side of the client/server relationship, and a corresponding
skeleton at the server end. The stub appears to the calling program to be the program
being called for a service. (Sun uses the term proxy as a synonym for stub.)
A Remote Reference Layer that can behave differently depending on the parameters
passed by the calling program. For example, this layer can determine whether the request
is to call a single remote service or multiple remote programs as in a multicast.
A Transport Connection Layer, which sets up and manages the request.
A single request travels down through the layers on one computer and up through the layers at
the other end.
RMI is supplied as part of Sun Microsystem's Java Development Kit (JDK).