Análisis de tiempo de espera de socket
El zócalo o socket (Socket) es una pieza de software en la forma de un resumen, la expresión para el "final" de una conexión entre dos máquinas. Para una conexión particular, cada máquina tiene un "socket", imagina que hay un "cable" virtual entre ellos. Hay dos clases basadas en JAVA las tomas de corriente de datos: ServerSocket, servidores utilizan para "escuchar" para las conexiones entrantes; zócalo, una vez que la conexión de cliente inicial con él. Escuchando toma sólo puede recibir una nueva solicitud de conexión no se puede recibir paquetes real.
Socket se basa en la implementación de TCP / IP, que se utiliza para proporcionar acceso a una interfaz de servicio TCP, o una aplicación de socket API de interfaz de programación de socket TCP, a través de la cual la capa de aplicación puede acceder a los servicios proporcionados por el TCP.
En JAVA, creamos un ServerSocket, clase Socket una conexión de socket, los resultados obtenidos de la toma es un InputStream y objetos OutputStream para ser conectado como un objeto de flujo de tratar IO. Se puede leer de la corriente por el flujo de datos IO o escritura de datos en la corriente, la corriente escribirá IO IOException excepción generada.
Toma de capa inferior se basa en TCP, el tiempo de espera de socket TCP y los tiempos de espera son los mismos. La siguiente primer tampón socket de escritura discusión, seguido de un establecimiento de tiempo de espera de conexión discusión, los tiempos de espera y el zócalo JAVA escritura programación captura excepción anidada y la captura de ejemplo ilustrativo de un procedimiento de tiempo de espera.
1 Toma de lectura y escritura tampones
Una vez que haya creado una instancia de toma, el sistema operativo para recibir y tampón para ser enviados serán asignados almacenar datos.
JAVA leer tamaño de memoria intermedia puede ser proporcionado -setReceiveBufferSize (tamaño int), setSendBufferSize (tamaño int).
datos de escritura con la corriente de salida no significa que los datos han sido enviados realmente, sino que se copian en la transmisión búfer cola SendQ, es llamar al método flush () en OutputStream zócalo, no podemos garantizar que los datos pueden ser enviados a la red inmediatamente. Una transmisión de datos real es tomada por los datos del módulo de pila de protocolo TCP sistema operativo transmitidos desde la memoria intermedia a la red para completar.
Cuando los datos llegan de la red, el módulo de pila de protocolo TCP recibe los datos y se coloca en el búfer de cola RECVQ, recuperar datos de la secuencia de entrada InputStream RECVQ por el método de lectura.
2 Toma de establecimiento de la conexión de tiempo de espera
conexión de socket se establece con base en el proceso de establecimiento de la conexión TCP. conexiones TCP requieren paquetes a través de un apretón de manos de 3 vías a completa, comenzaron a establecer las necesidades de sincronización para enviar un paquete SYN es una conexión TCP, y espera a que un mensaje de reconocimiento SYN + ACK, y, finalmente, envía un mensaje de confirmación ACK. conexión TCP cerrada por cuatro onda para completar un cierre activo de la conexión TCP transmite un paquete FIN, espera para un paquete de confirmación; pasiva cerró un paquete FIN también se transmite, y espera a que un mensaje de acuse de recibo.
Esperar TCP cola de petición de conexión conectado a un extremo de una longitud fija, conectado a la cola TCP ha sido aceptada (es decir, enlace de tres vías se ha completado), pero no ha sido aceptada por la capa de aplicación. Acepta se coloca una conexión TCP en la cola de conexión, la conexión de capa de aplicación se acepta que se retira de la cola. La capa de aplicación para indicar que la longitud máxima de las variables cola de registro de conexión de ajuste, aceptado por el TCP número máximo de conexiones ya la espera de la aceptación de capa de aplicación.
Cuando llega una petición de conexión SYN, TCP determina si acepta la conexión. Si hay espacio en la cola, el módulo TCP SYN será confirmar y completar el establecimiento de la conexión. Pero sólo en la capa de aplicación en los terceros paquetes de enlace de tres vías recibido usted sabrá esta nueva conexión. Si la cola hay espacio, TCP SYN ignorará la recibida.
Si el servidor no llega a aceptar una conexión TCP ha sido aceptado, estas conexiones se pueden llenar su cola, la nueva solicitud de conexión el tiempo de espera no puede responder. Si una transmisión SYN solicitud de conexión, ningún acuse de recibo se recibe después de un período de tiempo SYN + ACK, TCP retransmitirá la solicitud de conexión SYN dos veces, cada tiempo de duplicación del intervalo de retransmisión, aún no recibido dentro de un período de tiempo predeterminado SYN + ACK, TCP rechaza la solicitud de conexión, la conexión se establece en tiempo extra.
los tiempos de espera java socket, y establecimiento de conexión TCP son los mismos, si el enlace de tres vías TCP para establecer un tiempo de espera de conexión, entonces se lleva al establecimiento de la conexión de socket agotado el tiempo. Puede establecer el tiempo de establecimiento de conexión de socket -
connect (punto final SocketAddress, int timeout)
Si dentro del tiempo de espera, la conexión no se ha establecido correctamente, se produce una excepción en TimeoutException. Si el valor es menor que el tiempo de espera apretón de manos de tres vías, entonces no se establecerá la conexión de socket.
capas de aplicación diferentes tienen diferentes procesos de establecimiento de la conexión, establecimiento de la conexión de socket TCP y el mismo - sólo necesita de tres vías para completar la conexión, pero algunas aplicaciones requieren el lote interacción de información al éxito establecer una conexión, tales como el protocolo Telnet, de tres vías se completó en TCP más tarde, después de que la necesidad de la negociación de opciones, se estableció la conexión Telnet.
3 socket leer tiempo de espera
Si la cola de memoria intermedia de entrada RECVQ no hay datos, las operaciones de lectura habrían sido bloqueado y suspendido del hilo hasta que obtiene nuevos datos o se genera una excepción. Llamada setSoTimeout (int timeout) puede ajustar el tiempo de espera de tiempo de espera si no hay datos, sin embargo, lea lanzará una SocketTimeoutException, los procedimientos han de detectar esta excepción, pero la conexión de socket actual sigue siendo válida.
Si el otro proceso se bloquea, la otra máquina de repente reiniciado, desconectado de la red, al final de la lectura habría sido bloqueado abajo, a continuación, establecer los es muy importante, de lo contrario la llamada siempre se leerá el hilo cuelga de tiempo de espera.
módulo TCP convierte los datos recibidos en RECVQ hasta la capa de aplicación llama a la secuencia de entrada para leer el método de lectura. Si la cola está llena RECVQ, entonces notificar TCP mecanismo de deslizamiento de ventana de acuerdo con el otro no continúe a los datos de transmisión, el UE deja de recibir extremo partir de los datos de transmisión hasta que la aplicación destinatario llama al método de lectura de la secuencia de entrada desocupado espacio.
4 Toma de escribir la interrupción
tiempo de espera de toma de escritura se basa en el tiempo de espera de retransmisión de TCP. Tiempo de espera de retransmisión TCP es un mecanismo importante para garantizar la fiabilidad de la transmisión de datos, el principio es comenzar un temporizador después de enviar un mensaje de datos, si no es reconocido paquetes ACK enviado en un tiempo determinado, a continuación, volver a enviar paquetes Wen. Si después de re-enviado varias veces, todavía no hay mensaje de confirmación, se envía un paquete RST de reposición y, a continuación, cierra la conexión TCP. paquete de datos inicial y el tiempo entre el envío de un mensaje de restablecimiento de la transmisión diferencia de unos 9 minutos, es decir si el paquete no se confirma dentro de 9 minutos, se cierra la conexión. Sin embargo, este valor se basa en una aplicación diferente pila del protocolo TCP y diferente.
Si los datos de escritura llamada emisor está escrito de forma continua hasta que la cola está llena SendQ. Si se llama al método de escritura en la cola SendQ está lleno, entonces escritura será bloqueado hasta SendQ hasta que haya un nuevo espacio libre, esto es, hasta que el número de bytes transmitidos al receptor en el RECVQ zócalo. Si en este momento la cola RECVQ se ha llenado, todas las operaciones se detuvieron hasta que el extremo receptor de algunas llama al método de lectura de la transmisión de bytes a la aplicación.
Cuando los datos de transmisión de escritura de socket si se desconecta el cable, el extremo remoto de la máquina o el proceso de reinicio accidente, el módulo TCP retransmite los datos, y finalmente cierre el tiempo de espera de conexión. La próxima vez, como entonces llamada de escritura causará una excepción y salida.
Toma de escribir la interrupción mecanismo de tiempo de retransmisión se basa en la pila de protocolos TCP, en general, no es necesario poner el tiempo de escritura, que no proporcionó un procedimiento de este tipo.
5 excepción doble anidada atrapado
Si ServerSocket, zócalo de la construcción no sólo simplemente no pudo capturar la estructura anormal y sin la necesidad de llamar al método de cierre del zócalo para liberar recursos (debe estar garantizada para no dejar deberán ser liquidadas después de la construcción no todos los recursos), porque entonces el zócalo los recursos internos de palabras no se asignan correctamente. Si la construcción es exitosa, debe introducir un intento por último bloque de sentencias por los pelos en la liberación del zócalo. Por favor refiérase a los siguientes procedimientos de ejemplo.
importar java.net. *; import java.io. *; public class SocketClientTest {public static int última PORT = 8088; public static void Main (args String []) throws Exception {InetAddress dir = InetAddress.getByName ( "127.0.0.1"); Socket socket = new Socket (); try {Socket.connect (nueva InetSocketAddress (dir, PORT), 30000); socket.setSendBufferSize (100);
BufferedWriter out = new BufferedWriter( new OutputStreamWriter( socket.getOutputStream() ) );
int i = 0;
while( true )
{
System.out.println( "client sent --- hello *** " + i++ );
out.write( "client sent --- hello *** " + i );
out.flush();
Thread.sleep( 1000 );
}
}
finally
{
socket.close();
}
}
}
import java.io. *; java.net.ServerSocket importación; java.net.Socket importación; public class SocketServerTest {public static int última PORT = 8088; public static final de int BACKLOG = 2; public static void Main (args String []) throws IOException {server = ServerSocket nueva ServerSocket (PORT, BACKLOG); System.out.println ( "comenzó:" + servidor); try {Socket socket = server.accept (); try {BufferedReader en = new BufferedReader (nuevo InputStreamReader (socket.getInputStream ())); Información string = null;
while( ( info = in.readLine() ) != null )
{
System.out.println( info );
}
}
finally
{
socket.close();
}
}
finally
{
server.close();
}
}
}
Realizar el procedimiento anterior, después de un tiempo el programa se ejecuta, la desconexión entre la conexión del cliente y el servidor de red, en la salida de la máquina es el siguiente:
Servidor en la salida:
Haciendo eco: el cliente envía ----- hello0
Haciendo eco: el cliente envía ----- hello1
Haciendo eco: el cliente envía ----- hello2
Haciendo eco: el cliente envía ----- hello3
Haciendo eco: el cliente envía ----- hello4
Haciendo eco: el cliente envía ----- hello5
Haciendo eco: el cliente envía ----- hello6
No hay datos de salida después de que se desconecta la conexión de red ---- >>
Cliente en la salida:
socket predeterminado de tiempo de espera = 0
socket = Socket [addr = / 10.15.9.99, port = 8088, localport = 4691]
comenzar a leer
enviado cliente --- hola *** 0
enviado cliente --- hola *** 1
enviado cliente --- hola *** 2
enviado cliente --- hola *** 3
enviado cliente --- hola *** 4
enviado cliente --- hola *** 5
enviado cliente --- hola *** 6
enviado cliente --- hola *** 7
enviado cliente --- hola *** 8
enviado cliente --- hola *** 9
cliente envió --- hola *** 10
---- >> desconectado de la red después de un proceso de cliente está suspendido
java.net.SocketException : Conexión restablecida por el interlocutor: error de escritura de socket
en java.net.SocketOutputStream.socketWrite0 ( Nativo Método )
en java.net.SocketOutputStream.socketWrite ( SocketOutputStream.java:92 )
en java.net.SocketOutputStream.write ( SocketOutputStream.java:136 )
en sun.nio.cs.StreamEncoder.writeBytes ( StreamEncoder.java:202 )
en sun.nio.cs.StreamEncoder.implFlushBuffer ( StreamEncoder.java:272 )
en sun.nio.cs.StreamEncoder.implFlush ( StreamEncoder.java:276 )
en sun.nio.cs.StreamEncoder.flush ( StreamEncoder.java:122 )
en java.io.OutputStreamWriter.flush ( OutputStreamWriter.java:212 )
en java.io.BufferedWriter.flush ( BufferedWriter.java:236 )
en com.xtera.view.SocketClientTest.main ( SocketClientTest.java:99 )
Cuando el hello6 del lado del servidor se transmite a la conexión de red está desconectado, entonces el servidor no puede recibir cualquier dato pendiente. terminal del cliente sigue de transmisión de datos, de hecho hello7, hello8, hello9, hello10 SendQ se copian en la cola, devuelve el método de escritura de inmediato. Una vez que la cola del cliente se llena SendQ, se bloqueará método de escritura. Después de que el módulo de TCP envía paquetes hello7, no hemos recibido la retransmisión de tiempo de espera de acuse de recibo, retransmitir varias veces después de cerrar la conexión TCP, mientras que causan devuelve el método de escritura anormales bloqueados.
A través de la herramienta de captura de paquetes, podemos ver que los paquetes de tiempo de espera de retransmisión.
