net.i2p.client.streaming

## Class ConnectionHandler

- java.lang.Object
- - net.i2p.client.streaming.ConnectionHandler

-      class ConnectionHandler
      extends Object

  Receive new connection attempts Use a bounded queue to limit the damage from SYN floods, router overload, or a slow client
  Author:
    zzz modded to use concurrent and bound queue size

- - ### Constructor Summary

    Constructors
    Constructor and Description
    `ConnectionHandler(I2PAppContext context, ConnectionManager mgr)` Creates a new instance of ConnectionHandler

  - ### Method Summary

    Methods
    Modifier and Type | Method and Description
    --- | ---
    `Connection` | `accept(long timeoutMs)` Receive an incoming connection (built from a received SYN) Non-SYN packets with a zero SendStreamID may also be queued here so that they don't get thrown away while the SYN packet before it is queued.
    `boolean` | `getActive()`
    `void` | `receiveNewSyn(Packet packet)` Non-SYN packets with a zero SendStreamID may also be queued here so that they don't get thrown away while the SYN packet before it is queued.
    `void` | `setActive(boolean active)`

    - ### Methods inherited from class java.lang.Object

      `clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait`

- - ### Constructor Detail

    - #### ConnectionHandler

          public ConnectionHandler(I2PAppContext context,
                           ConnectionManager mgr)

      Creates a new instance of ConnectionHandler

  - ### Method Detail

    - #### setActive

          public void setActive(boolean active)

    - #### getActive

          public boolean getActive()

    - #### receiveNewSyn

          public void receiveNewSyn(Packet packet)

      Non-SYN packets with a zero SendStreamID may also be queued here so that they don't get thrown away while the SYN packet before it is queued. Additional overload protection may be required here... We don't have a 3-way handshake, so the SYN fully opens a connection. Does that make us more or less vulnerable to SYN flooding?

    - #### accept

          public Connection accept(long timeoutMs)

      Receive an incoming connection (built from a received SYN) Non-SYN packets with a zero SendStreamID may also be queued here so that they don't get thrown away while the SYN packet before it is queued.
      Parameters:
        `timeoutMs` - max amount of time to wait for a connection (if less than 1ms, wait indefinitely)
      Returns:
        connection received, or null if there was a timeout or the handler was shut down