| The ServerSocket class contains everything needed to write servers in Java. It has constructors that create new ServerSocket objects, methods that listen for connections on a specified port, methods that configure the various server socket options, and the usual miscellaneous methods such as toString( ) . In Java, the basic life cycle of a server program is: -
A new ServerSocket is created on a particular port using a ServerSocket( ) constructor. -
The ServerSocket listens for incoming connection attempts on that port using its accept( ) method. accept( ) blocks until a client attempts to make a connection, at which point accept( ) returns a Socket object connecting the client and the server. -
Depending on the type of server, either the Socket 's getInputStream() method, getOutputStream( ) method, or both are called to get input and output streams that communicate with the client. -
The server and the client interact according to an agreed-upon protocol until it is time to close the connection. -
The server, the client, or both close the connection. -
The server returns to step 2 and waits for the next connection. If step 4 is likely to take a long or indefinite amount of time, traditional Unix servers such as wu- ftpd create a new process to handle each connection so that multiple clients can be serviced at the same time. Java programs should spawn a thread to interact with the client so that the server can be ready to process the next connection sooner. A thread places a far smaller load on the server than a complete child process. In fact, the overhead of forking too many processes is why the typical Unix FTP server can't handle more than roughly 400 connections without slowing to a crawl. On the other hand, if the protocol is simple and quick and allows the server to close the connection when it's through, then it will be more efficient for the server to process the client request immediately without spawning a thread.  | Although threads are lighter-weight than processes on most systems (Linux is the notable exception), too many threads can still be a performance problem. For instance, on most VMs each thread requires about a megabyte of RAM above and beyond what the rest of the program needs. Thus, on a typical modern server with about a gigabyte of RAM, anything close to or beyond a thousand threads is likely to slow down dramatically and eventually crash as the CPU violently and frequently swaps data into and out of RAM. Spawning too many threads is one of the few ways you can reliably crash any Java virtual machine. Java 1.4 introduces a ServerSocketChannel class that provides non-blocking , multiplexed I/O based on channels rather than streams. With channels, a single thread can process multiple connections, thereby requiring many fewer threads and placing a much smaller load on the VM. This can be highly advantageous for high volume servers on some operating systems. I'll discuss these kinds of servers in Chapter 12. For simple, low-volume servers or any servers that need to run with Java 1.3 or earlier, the techniques discussed in this chapter should be used. | |
The operating system stores incoming connection requests addressed to a particular port in a first-in, first-out queue. The default length of the queue is normally 50, although it can vary from operating system to operating system. Some operating systems (not Solaris) have a maximum queue length, typically five. On these systems, the queue length will be the largest possible value less than or equal to 50. After the queue fills to capacity with unprocessed connections, the host refuses additional connections on that port until slots in the queue open up. Many (though not all) clients will try to make a connection multiple times if their initial attempt is refused . The operating system manages incoming connections and the queue; your program does not need to worry about it. Several ServerSocket constructors allow you to change the length of the queue if its default length isn't large enough; however, you won't be able to increase the queue beyond the maximum size that the operating system supports. 10.1.1 The Constructors There are four public ServerSocket constructors: public ServerSocket(int port) throws BindException, IOException public ServerSocket(int port, int queueLength) throws BindException, IOException public ServerSocket(int port, int queueLength, InetAddress bindAddress) throws IOException public ServerSocket( ) throws IOException // Java 1.4
These constructors let you specify the port, the length of the queue used to hold incoming connection requests, and the local network interface to bind to. They pretty much all do the same thing, though some use default values for the queue length and the address to bind to. Let's explore these in order. 10.1.1.1 public ServerSocket(int port) throws BindException, IOException This constructor creates a server socket on the port specified by the argument. If you pass 0 for the port number, the system selects an available port for you. A port chosen for you by the system is sometimes called an anonymous port since you don't know its number. For servers, anonymous ports aren't very useful because clients need to know in advance which port to connect to; however, there are a few situations (which we will discuss later) in which an anonymous port might be useful. For example, to create a server socket that would be used by an HTTP server on port 80, you would write: try { ServerSocket httpd = new ServerSocket(80); } catch (IOException ex) { System.err.println(ex); }
The constructor throws an IOException ( specifically , a BindException ) if the socket cannot be created and bound to the requested port. An IOException when creating a ServerSocket almost always means one of two things. Either another server socket, possibly from a completely different program, is already using the requested port, or you're trying to connect to a port from 1 to 1,023 on Unix (including Linux and Mac OS X) without root (superuser) privileges. You can use this constructor to write a variation on the PortScanner programs of the previous chapter. Example 10-1 checks for ports on the local machine by attempting to create ServerSocket objects on them and seeing on which ports that fails. If you're using Unix and are not running as root, this program works only for ports 1,024 and above. Example 10-1. Look for local ports import java.net.*; import java.io.*; public class LocalPortScanner { public static void main(String[] args) { for (int port = 1; port <= 65535; port++) { try { // the next line will fail and drop into the catch block if // there is already a server running on the port ServerSocket server = new ServerSocket(port); } catch (IOException ex) { System.out.println("There is a server on port " + port + "."); } // end catch } // end for } }
Here's the output I got when running LocalPortScanner on my Windows NT 4.0 workstation: D:\JAVA\JNP2\examples> java LocalPortScanner There is a server on port 135. There is a server on port 1025. There is a server on port 1026. There is a server on port 1027. There is a server on port 1028.
10.1.1.2 public ServerSocket(int port, int queueLength) throws IOException, BindException This constructor opens a server socket on the specified port with a queue length of your choosing. If the machine has multiple network interfaces or IP addresses, then it listens on this port on all those interfaces and IP addresses. The queueLength argument sets the length of the queue for incoming connection requeststhat is, how many incoming connections can be stored at one time before the host starts refusing connections. Some operating systems have a maximum queue length, typically five. If you try to expand the queue past that maximum number, the maximum queue length is used instead. If you pass 0 for the port number, the system selects an available port. For example, to create a server socket on port 5,776 that would hold up to 100 incoming connection requests in the queue, you would write: try { ServerSocket httpd = new ServerSocket(5776, 100); } catch (IOException ex) { System.err.println(ex); }
The constructor throws an IOException (specifically, a BindException ) if the socket cannot be created and bound to the requested port. However, no exception is thrown if the queue length is larger than the host OS supports. Instead, the queue length is simply set to the maximum size allowed. 10.1.1.3 public ServerSocket(int port, int queueLength, InetAddress bindAddress) throws BindException, IOException This constructor binds a server socket to the specified port with the specified queue length. It differs from the other two constructors in binding only to the specified local IP address. This constructor is useful for servers that run on systems with several IP addresses because it allows you to choose the address to which you'll listen. That is, the server socket only listens for incoming connections on the specified address; it won't listen for connections that come in through the host's other addresses. The previous two constructors bind to all local IP addresses by default. For example, login. ibiblio .org is a particular Linux box in North Carolina. It's connected to the Internet with the IP address 152.2.210.122. The same box has a second Ethernet card with the local IP address 192.168.210.122 that is not visible from the public Internet, only from the local network. If for some reason I wanted to run a server on this host that only responded to local connections from within the same network, I could create a server socket that listens on port 5,776 of 192.168.210.122 but not on port 5,776 of 152.2.210.122, like so: try { ServerSocket httpd = new ServerSocket(5776, 10, InetAddress.getByName("192.168.210.122")); } catch (IOException ex) { System.err.println(ex); }
The constructor throws an IOException (again, really a BindException ) if the socket cannot be created and bound to the requested port or network interface. 10.1.1.4 public ServerSocket( ) throws IOException // Java 1.4 The public no-args constructor is new in Java 1.4. It creates a ServerSocket object but does not actually bind it to a port so it cannot initially accept any connections. It can be bound later using the bind() methods also introduced in Java 1.4: public void bind(SocketAddress endpoint) throws IOException // Java 1.4 public void bind(SocketAddress endpoint, int queueLength) // Java 1.4 throws IOException
The primary use for this feature is to allow programs to set server socket options before binding to a port. Some options are fixed after the server socket has been bound. The general pattern looks like this: ServerSocket ss = new ServerSocket( ); // set socket options... SocketAddress http = new InetSocketAddress(80); ss.bind(http);
You can also past null for the SocketAddress to select an arbitrary port. This is like passing 0 for the port number in the other constructors. 10.1.2 Accepting and Closing Connections A ServerSocket customarily operates in a loop that repeatedly accepts connections. Each pass through the loop invokes the accept( ) method. This returns a Socket object representing the connection between the remote client and the local server. Interaction with the client takes place through this Socket object. When the transaction is finished, the server should invoke the Socket object's close() method. If the client closes the connection while the server is still operating, the input and/or output streams that connect the server to the client throw an InterruptedIOException on the next read or write. In either case, the server should then get ready to process the next incoming connection. However, when the server needs to shut down and not process any further incoming connections, you should invoke the ServerSocket object's close( ) method. 10.1.2.1 public Socket accept( ) throws IOException When server setup is done and you're ready to accept a connection, call the ServerSocket 's accept() method. This method "blocks"; that is, it stops the flow of execution and waits until a client connects. When a client does connect, the accept( ) method returns a Socket object. You use the streams returned by this Socket 's getInputStream( ) and getOutputStream( ) methods to communicate with the client. For example: ServerSocket server = new ServerSocket(5776); while (true) { Socket connection = server.accept( ); OutputStreamWriter out = new OutputStreamWriter(connection.getOutputStream( )); out.write("You've connected to this server. Bye-bye now.\r\n"); connection.close( ); }
If you don't want the program to halt while it waits for a connection, put the call to accept( ) in a separate thread. | | If you're using Java 1.4 or later, you have the option to use channels and non-blocking I/O instead of threads. In some (not all) virtual machines, this is much faster than using streams and threads. These techniques will be discussed in Chapter 12. | |
When exception handling is added, the code becomes somewhat more convoluted. It's important to distinguish between exceptions that should probably shut down the server and log an error message, and exceptions that should just close that active connection. Exceptions thrown by accept( ) or the input and output streams generally should not shut down the server. Most other exceptions probably should. To do this, you'll need to nest your try blocks. Finally, most servers will want to make sure that all sockets they accept are closed when they're finished. Even if the protocol specifies that clients are responsible for closing connections, clients do not always strictly adhere to the protocol. The call to close( ) also has to be wrapped in a try block that catches an IOException . However, if you do catch an IOException when closing the socket, ignore it. It just means that the client closed the socket before the server could. Here's a slightly more realistic example: try { ServerSocket server = new ServerSocket(5776); while (true) { Socket connection = server.accept( ); try { Writer out = new OutputStreamWriter(connection.getOutputStream( )); out.write("You've connected to this server. Bye-bye now.\r\n"); out.flush( ); connection.close( ); } catch (IOException ex) { // This tends to be a transitory error for this one connection; // e.g. the client broke the connection early. Consequently, // you don't want to break the loop or print an error message. // However, you might choose to log this exception in an error log. } finally { // Guarantee that sockets are closed when complete. try { if (connection != null) connection.close( ); } catch (IOException ex) {} } } catch (IOException ex) { System.err.println(ex); }
Example 10-2 implements a simple daytime server, as per RFC 867. Since this server just sends a single line of text in response to each connection, it processes each connection immediately. More complex servers should spawn a thread to handle each request. In this case, the overhead of spawning a thread would be greater than the time needed to process the request. | | If you run this program on Unix (including Linux and Mac OS X), you need to run it as root in order to connect to port 13. If you don't want to or can't run it as root, change the port number to something above 1024say, 1313. | |
Example 10-2. A daytime server import java.net.*; import java.io.*; import java.util.Date; public class DaytimeServer { public final static int DEFAULT_PORT = 13; public static void main(String[] args) { int port = DEFAULT_PORT; if (args.length > 0) { try { port = Integer.parseInt(args[0]); if (port < 0 port >= 65536) { System.out.println("Port must between 0 and 65535"); return; } } catch (NumberFormatException ex) { // use default port } } try { ServerSocket server = new ServerSocket(port); Socket connection = null; while (true) { try { connection = server.accept( ); Writer out = new OutputStreamWriter(connection.getOutputStream( )); Date now = new Date( ); out.write(now.toString( ) +"\r\n"); out.flush( ); connection.close( ); } catch (IOException ex) {} finally { try { if (connection != null) connection.close( ); } catch (IOException ex) {} } } // end while } // end try catch (IOException ex) { System.err.println(ex); } // end catch } // end main } // end DaytimeServer
Example 10-2 is straightforward. The first three lines import the usual packages, java.io and java.net , as well as java.util.Date , which provides the time as read by the server's internal clock. There is a single public final static int field (i.e., a constant) in the class DEFAULT_PORT , which is set to the well-known port for a daytime server (port 13). The class has a single method, main( ) , which does all the work. If the port is specified on the command line, then it's read from args[0] . Otherwise, the default port is used. The outer try block traps any IOException s that may arise while the ServerSocket object server is constructed on the daytime port or when it accepts connections. The inner try block watches for exceptions thrown while the connections are accepted and processed . The accept( ) method is called within an infinite loop to watch for new connections; like many servers, this program never terminates but continues listening until an exception is thrown or you stop it manually. | | The command for stopping a program manually depends on your system; under Unix, NT, and many other systems, CTRL-C will do the job. If you are running the server in the background on a Unix system, stop it by finding the server's process ID and killing it with the kill command ( kill pid ) . | |
When a client connects, accept( ) returns a Socket , which is stored in the local variable connection , and the program continues. It calls getOutputStream( ) to get the output stream associated with that Socket and then chains that output stream to a new OutputStreamWriter , out . A new Date object provides the current time. The content is sent to the client by writing its string representation on out with write() . Finally, after the data is sent or an exception has been thrown, the finally block closes the connection . Always close a socket when you're finished with it. In the previous chapter, I said that a client shouldn't rely on the other side of a connection to close the socket: that goes triple for servers. Clients time out or crash; users cancel transactions; networks go down in high-traffic periods. For any of these or a dozen more reasons, you cannot rely on clients to close sockets, even when the protocol requires them to, which this one doesn't. Sending binary, nontext data is not significantly harder. Example 10-3 demonstrates with a time server that follows the time protocol outlined in RFC 868. When a client connects, the server sends a 4-byte, big-endian, unsigned integer specifying the number of seconds that have passed since 12:00 A.M., January 1, 1900 GMT (the epoch ). Once again, the current time is found by creating a new Date object. However, since the Date class counts milliseconds since 12:00 A.M., January 1, 1970 GMT rather than seconds since 12:00 A.M., January 1, 1900 GMT, some conversion is necessary. Example 10-3. A time server import java.net.*; import java.io.*; import java.util.Date; public class TimeServer { public final static int DEFAULT_PORT = 37; public static void main(String[] args) { int port = DEFAULT_PORT; if (args.length > 0) { try { port = Integer.parseInt(args[0]); if (port < 0 port >= 65536) { System.out.println("Port must between 0 and 65535"); return; } } catch (NumberFormatException ex) {} } // The time protocol sets the epoch at 1900, // the Date class at 1970. This number // converts between them. long differenceBetweenEpochs = 2208988800L; try { ServerSocket server = new ServerSocket(port); while (true) { Socket connection = null; try { connection = server.accept( ); OutputStream out = connection.getOutputStream( ); Date now = new Date( ); long msSince1970 = now.getTime( ); long secondsSince1970 = msSince1970/1000; long secondsSince1900 = secondsSince1970 + differenceBetweenEpochs; byte[] time = new byte[4]; time[0] = (byte) ((secondsSince1900 & 0x00000000FF000000L) >> 24); time[1] = (byte) ((secondsSince1900 & 0x0000000000FF0000L) >> 16); time[2] = (byte) ((secondsSince1900 & 0x000000000000FF00L) >> 8); time[3] = (byte) (secondsSince1900 & 0x00000000000000FFL); out.write(time); out.flush( ); } // end try catch (IOException ex) { } // end catch finally { if (connection != null) connection.close( ); } } // end while } // end try catch (IOException ex) { System.err.println(ex); } // end catch } // end main } // end TimeServer
As with the TimeClient of the previous chapter, most of the effort here goes into working with a data format (32-bit unsigned integers) that Java doesn't natively support. 10.1.2.2 public void close( ) throws IOException If you're finished with a server socket, you should close it, especially if the program is going to continue to run for some time. This frees up the port for other programs that may wish to use it. Closing a ServerSocket should not be confused with closing a Socket . Closing a ServerSocket frees a port on the local host, allowing another server to bind to the port; it also breaks all currently open sockets that the ServerSocket has accepted. Server sockets are closed automatically when a program dies, so it's not absolutely necessary to close them in programs that terminate shortly after the ServerSocket is no longer needed. Nonetheless, it doesn't hurt. For example, the main loop of the LocalPortScanner program might be better written like this so that it doesn't temporarily occupy most of the ports on the system: for (int port = 1; port <= 65535; port++) { try { // the next line will fail and drop into the catch block if // there is already a server running on the port ServerSocket server = new ServerSocket(port); server.close( ); } catch (IOException ex) { System.out.println("There is a server on port " + port + "."); } } // end for
After the server socket has been closed, it cannot be reconnected, even to the same port. Java 1.4 adds an isClosed( ) method that returns true if the ServerSocket has been closed, false if it hasn't: public boolean isClosed( ) // Java 1.4
ServerSocket objects that were created with the no-args ServerSocket( ) constructor and not yet bound to a port are not considered to be closed. Invoking isClosed( ) on these objects returns false. Java 1.4 also adds an isBound( ) method that tells you whether the ServerSocket has been bound to a port: public boolean isBound( ) // Java 1.4
As with the isBound( ) method of the Socket class discussed in the last chapter, the name is a little misleading. isBound( ) returns true if the ServerSocket has ever been bound to a port, even if it's currently closed. If you need to test whether a ServerSocket is open, you must check both that isBound( ) returns true and that isClosed( ) returns false. For example: public static boolean isOpen(ServerSocket ss) { return ss.isBound( ) && ! ss.isClosed( ); }
10.1.3 The get Methods The ServerSocket class provides two getter methods that tell you the local address and port occupied by the server socket. These are useful if you've opened a server socket on an anonymous port and/or an unspecified network interface. This would be the case, for one example, in the data connection of an FTP session. 10.1.3.1 public InetAddress getInetAddress( ) This method returns the address being used by the server (the local host). If the local host has a single IP address (as most do), this is the address returned by InetAddress.getLocalHost( ) . If the local host has more than one IP address, the specific address returned is one of the host's IP addresses. You can't predict which address you will get. For example: ServerSocket httpd = new ServerSocket(80); InetAddress ia = httpd.getInetAddress( );
If the ServerSocket has not yet bound to a network interface, this method returns null. 10.1.3.2 public int getLocalPort( ) The ServerSocket constructors allow you to listen on an unspecified port by passing 0 for the port number. This method lets you find out what port you're listening on. You might use this in a peer-to-peer multisocket program where you already have a means to inform other peers of your location. Or a server might spawn several smaller servers to perform particular operations. The well-known server could inform clients what ports they can find the smaller servers on. Of course, you can also use getLocalPort() to find a non-anonymous port, but why would you need to? Example 10-4 demonstrates. Example 10-4. A random port import java.net.*; import java.io.*; public class RandomPort { public static void main(String[] args) { try { ServerSocket server = new ServerSocket(0); System.out.println("This server runs on port " + server.getLocalPort( )); } catch (IOException ex) { System.err.println(ex); } } }
Here's the output of several runs: D:\JAVA\JNP3\examples> java RandomPort This server runs on port 1154 D:\JAVA\JNP3\examples> java RandomPort This server runs on port 1155 D:\JAVA\JNP3\examples> java RandomPort This server runs on port 1156
At least on this VM, the ports aren't really random, but they are at least indeterminate until runtime. If the ServerSocket has not yet bound to a port, then this method returns -1. 10.1.4 Socket Options Java 1.3 only supports one socket option for server sockets, SO_TIMEOUT. Java 1.4 adds two more, SO_REUSEADDR and SO_RCVBUF. 10.1.4.1 SO_TIMEOUT SO_TIMEOUT is the amount of time, in milliseconds, that accept( ) waits for an incoming connection before throwing a java.io.InterruptedIOException . If SO_TIMEOUT is 0, accept( ) will never time out. The default is to never time out. Using SO_TIMEOUT is rather rare. You might need it if you were implementing a complicated and secure protocol that required multiple connections between the client and the server where responses needed to occur within a fixed amount of time. However, most servers are designed to run for indefinite periods of time and therefore just use the default timeout value, 0 (never time out). If you want to change this, the setSoTimeout( ) method sets the SO_TIMEOUT field for this server socket object. public void setSoTimeout(int timeout) throws SocketException public int getSoTimeout( ) throws IOException
The countdown starts when accept() is invoked. When the timeout expires , accept( ) throws an InterruptedIOException . (In Java 1.4, it throws SocketTimeoutException , a subclass of InterruptedIOException .) You should set this option before calling accept( ) ; you cannot change the timeout value while accept( ) is waiting for a connection. The timeout argument must be greater than or equal to zero; if it isn't, the method throws an IllegalArgumentException . For example: try { ServerSocket server = new ServerSocket(2048); server.setSoTimeout(30000); // block for no more than 30 seconds try { Socket s = server.accept( ); // handle the connection // ... } catch (InterruptedIOException ex) { System.err.println("No connection within 30 seconds"); } finally { server.close( ); } catch (IOException ex) { System.err.println("Unexpected IOException: " + e); }
The getSoTimeout() method returns this server socket's current SO_TIMEOUT value. For example: public void printSoTimeout(ServerSocket server) { int timeout = server.getSoTimeOut( ); if (timeout > 0) { System.out.println(server + " will time out after " + timeout + "milliseconds."); } else if (timeout == 0) { System.out.println(server + " will never time out."); } else { System.out.println("Impossible condition occurred in " + server); System.out.println("Timeout cannot be less than zero." ); } }
10.1.4.2 SO_REUSEADDR // Java 1.4 The SO_REUSEADDR option for server sockets is very similar to the same option for client sockets, discussed in the last chapter. It determines whether a new socket will be allowed to bind to a previously used port while there might still be data traversing the network addressed to the old socket. As you probably expect, there are two methods to get and set this option: public void setReuseAddress(boolean on) throws SocketException public boolean getReuseAddress( ) throws SocketException
The default value is platform-dependent. This code fragment determines the default value by creating a new ServerSocket and then calling getReuseAddress( ) : ServerSocket ss = new ServerSocket(10240); System.out.println("Reusable: " + ss.getReuseAddress( ));
On the Linux and Mac OS X boxes where I tested this code, server sockets were reusable. 10.1.4.3 SO_RCVBUF // Java 1.4 The SO_RCVBUF option sets the default receive buffer size for client sockets accepted by the server socket. It's read and written by these two methods: public void setReceiveBufferSize(int size) throws SocketException public int getReceiveBufferSize( ) throws SocketException
Setting SO_RCVBUF on a server socket is like calling setReceiveBufferSize( ) on each individual socket returned by accept( ) (except that you can't change the receive buffer size after the socket has been accepted). Recall from the last chapter that this option suggests a value for the size of the individual IP packets in the stream. Faster connections will want to use larger packets, although most of the time the default value is fine. You can set this option before or after the server socket is bound, unless you want to set a receive buffer size larger than 64K. In that case, you must set the option on an unbound ServerSocket before binding it. For example: ServerSocket ss = new ServerSocket( ); int receiveBufferSize = ss.getReceiveBufferSize( ); if (receiveBufferSize < 131072) { ss.setReceiveBufferSize(131072); } ss.bind(new InetSocketAddress(8000)); //...
10.1.4.4 public void setPerformancePreferences(int connectionTime, int latency, int bandwidth) // Java 1.5 Java 1.5 adds a slightly different method for setting socket optionsthe setPerformancePreferences() method: public void setPerformancePreferences(int connectionTime, int latency, int bandwidth)
This method expresses the relative preferences given to connection time, latency, and bandwidth. For instance, if connectionTime is 2 and latency is 1 and bandwidth is 3, then maximum bandwidth is the most important characteristic, minimum latency is the least important, and connection time is in the middle. Exactly how any given VM implements this is implementation-dependent. Indeed, it may be a no-op in some implementations . The API documentation for ServerSocket even suggests using non-TCP/IP sockets, although it's not at all clear what that means. 10.1.5 The Object Methods ServerSocket overrides only one of the standard methods from java.lang.Object , toString( ) . Thus, equality comparisons test for strict identity and server sockets are problematic in hash tables. Normally, this isn't a large problem. 10.1.5.1 public String toString( ) A String returned by ServerSocket 's toString( ) method looks like this: ServerSocket[addr=0.0.0.0,port=0,localport=5776]
addr is the address of the local network interface to which the server socket is bound. This will be 0.0.0.0 if it's bound to all interfaces, as is commonly the case. port is always 0. The localport is the local port on which the server is listening for connections. This method is sometimes useful for debugging, but not much more. Don't rely on it. 10.1.6 Implementation The ServerSocket class provides two methods for changing the default implementation of server sockets. I'll describe them only briefly here, since they're primarily intended for implementers of Java virtual machines rather than application programmers. 10.1.6.1 public static void setSocketFactory(SocketImplFactory factory) throws IOException This method sets the system's server SocketImplFactory , which is the factory used to create ServerSocket objects. This is not the same factory that is used to create client Socket objects, though the syntax is similar; you can have one factory for Socket objects and a different factory for ServerSocket objects. You can set this factory only once in a program, however. A second attempt to set the SocketImplFactory throws a SocketException . 10.1.6.2 protected final void implAccept(Socket s) throws IOException Subclasses of ServerSocket use this method when they want to override accept( ) so that it returns an instance of their own custom Socket subclass rather than a plain java.net.Socket . The overridden accept( ) method passes its own unconnected Socket object to this method to actually make the connection. You pass an unconnected Socket object to implAccept( ) . When implAccept( ) returns, the Socket argument s is connected to a client. For example: public Socket accept( ) throws IOException { Socket s = new MySocketSubclass( ); implAccept(s); return s; }
If the server needs to know that the Socket returned by accept( ) has a more specific type than just java.net.Socket , it must cast the return value appropriately. For example: ServerSocket server = new MyServerSocketSubclass(80); while (true) { MySocketSubclass socket = (MySocketSubclass) server.accept( );; // ... }
| 