440
441 @Override
442 public synchronized void setEnableSessionCreation(boolean flag) {
443 conContext.sslConfig.enableSessionCreation = flag;
444 }
445
446 @Override
447 public synchronized boolean getEnableSessionCreation() {
448 return conContext.sslConfig.enableSessionCreation;
449 }
450
451 @Override
452 public boolean isClosed() {
453 return tlsIsClosed;
454 }
455
456 // Please don't synchronized this method. Otherwise, the read and close
457 // locks may be deadlocked.
458 @Override
459 public void close() throws IOException {
460 if (tlsIsClosed) {
461 return;
462 }
463
464 if (SSLLogger.isOn && SSLLogger.isOn("ssl")) {
465 SSLLogger.fine("duplex close of SSLSocket");
466 }
467
468 try {
469 // shutdown output bound, which may have been closed previously.
470 if (!isOutputShutdown()) {
471 duplexCloseOutput();
472 }
473
474 // shutdown input bound, which may have been closed previously.
475 if (!isInputShutdown()) {
476 duplexCloseInput();
477 }
478
479 if (!isClosed()) {
480 // close the connection directly
481 closeSocket(false);
482 }
483 } catch (IOException ioe) {
484 // ignore the exception
485 if (SSLLogger.isOn && SSLLogger.isOn("ssl")) {
486 SSLLogger.warning("SSLSocket duplex close failed", ioe);
487 }
488 } finally {
489 tlsIsClosed = true;
490 }
491 }
492
493 /**
494 * Duplex close, start from closing outbound.
495 *
496 * For TLS 1.2 [RFC 5246], unless some other fatal alert has been
497 * transmitted, each party is required to send a close_notify alert
498 * before closing the write side of the connection. The other party
499 * MUST respond with a close_notify alert of its own and close down
500 * the connection immediately, discarding any pending writes. It is
501 * not required for the initiator of the close to wait for the responding
502 * close_notify alert before closing the read side of the connection.
503 *
504 * For TLS 1.3, Each party MUST send a close_notify alert before
505 * closing its write side of the connection, unless it has already sent
506 * some error alert. This does not have any effect on its read side of
507 * the connection. Both parties need not wait to receive a close_notify
508 * alert before closing their read side of the connection, though doing
509 * so would introduce the possibility of truncation.
|
440
441 @Override
442 public synchronized void setEnableSessionCreation(boolean flag) {
443 conContext.sslConfig.enableSessionCreation = flag;
444 }
445
446 @Override
447 public synchronized boolean getEnableSessionCreation() {
448 return conContext.sslConfig.enableSessionCreation;
449 }
450
451 @Override
452 public boolean isClosed() {
453 return tlsIsClosed;
454 }
455
456 // Please don't synchronized this method. Otherwise, the read and close
457 // locks may be deadlocked.
458 @Override
459 public void close() throws IOException {
460 if (isClosed()) {
461 return;
462 }
463
464 if (SSLLogger.isOn && SSLLogger.isOn("ssl")) {
465 SSLLogger.fine("duplex close of SSLSocket");
466 }
467
468 try {
469 if (isConnected()) {
470 // shutdown output bound, which may have been closed previously.
471 if (!isOutputShutdown()) {
472 duplexCloseOutput();
473 }
474
475 // shutdown input bound, which may have been closed previously.
476 if (!isInputShutdown()) {
477 duplexCloseInput();
478 }
479 }
480 } catch (IOException ioe) {
481 // ignore the exception
482 if (SSLLogger.isOn && SSLLogger.isOn("ssl")) {
483 SSLLogger.warning("SSLSocket duplex close failed", ioe);
484 }
485 } finally {
486 if (!isClosed()) {
487 // close the connection directly
488 try {
489 closeSocket(false);
490 } catch (IOException ioe) {
491 // ignore the exception
492 if (SSLLogger.isOn && SSLLogger.isOn("ssl")) {
493 SSLLogger.warning("SSLSocket close failed", ioe);
494 }
495 } finally {
496 tlsIsClosed = true;
497 }
498 }
499 }
500 }
501
502 /**
503 * Duplex close, start from closing outbound.
504 *
505 * For TLS 1.2 [RFC 5246], unless some other fatal alert has been
506 * transmitted, each party is required to send a close_notify alert
507 * before closing the write side of the connection. The other party
508 * MUST respond with a close_notify alert of its own and close down
509 * the connection immediately, discarding any pending writes. It is
510 * not required for the initiator of the close to wait for the responding
511 * close_notify alert before closing the read side of the connection.
512 *
513 * For TLS 1.3, Each party MUST send a close_notify alert before
514 * closing its write side of the connection, unless it has already sent
515 * some error alert. This does not have any effect on its read side of
516 * the connection. Both parties need not wait to receive a close_notify
517 * alert before closing their read side of the connection, though doing
518 * so would introduce the possibility of truncation.
|