Package net.i2p.client.streaming.impl

Class ConnectionOptions

  • All Implemented Interfaces:
    I2PSocketOptions
    class ConnectionOptions
extends I2PSocketOptionsImpl
    Define the current options for the con (and allow custom tweaking midstream) TODO many of these are not per-connection options, and should be migrated somewhere so they aren't copied for every connection

    • Field Detail

      • INACTIVITY_ACTION_NOOP

        public static final int INACTIVITY_ACTION_NOOP
        on inactivity timeout, do nothing
        See Also:
        Constant Field Values

      • INACTIVITY_ACTION_DISCONNECT

        public static final int INACTIVITY_ACTION_DISCONNECT
        on inactivity timeout, close the connection
        See Also:
        Constant Field Values

      • INACTIVITY_ACTION_SEND

        public static final int INACTIVITY_ACTION_SEND
        on inactivity timeout, send a payload message
        See Also:
        Constant Field Values

      • PROP_CONGESTION_AVOIDANCE_GROWTH_RATE_FACTOR

        public static final String PROP_CONGESTION_AVOIDANCE_GROWTH_RATE_FACTOR
        See Also:
        Constant Field Values

      • PROP_ENABLE_ACCESS_LIST

        public static final String PROP_ENABLE_ACCESS_LIST
        all of these are @since 0.7.13
        See Also:
        Constant Field Values

      • PROP_MAX_STREAMS

        public static final String PROP_MAX_STREAMS
        how many streams will we allow at once?
        Since:
        0.9.3 moved from I2PSocketManagerFull
        See Also:
        Constant Field Values

      • PROP_LIMIT_ACTION

        public static final String PROP_LIMIT_ACTION
        Since:
        0.9.34 reset,drop,http, or custom string, default reset
        See Also:
        Constant Field Values

      • INITIAL_WINDOW_SIZE

        static final int INITIAL_WINDOW_SIZE
        RFC 5681 sec. 3.1
        See Also:
        Constant Field Values

      • DEFAULT_TAGS_TO_SEND

        public static final int DEFAULT_TAGS_TO_SEND
        Since:
        0.9.34
        See Also:
        Constant Field Values

      • DEFAULT_TAG_THRESHOLD

        public static final int DEFAULT_TAG_THRESHOLD
        Since:
        0.9.34
        See Also:
        Constant Field Values

      • DEFAULT_MAX_MESSAGE_SIZE

        public static final int DEFAULT_MAX_MESSAGE_SIZE
        OK, here is the calculation on the message size to fit in a single tunnel message without fragmentation. This is based on documentation, the code, and logging, however there are still some parts that could use more research. 
          1024 Tunnel Message
  - 21 Header (see router/tunnel/BatchedPreprocessor.java)
 -----
  1003 Tunnel Payload
  - 39 Unfragmented instructions (see router/tunnel/TrivialPreprocessor.java)
 -----
   964 Garlic Message
  - 16 I2NP header
  -  4 length
 -----
   944 Garlic Message AES payload padded to 16 bytes
  -  0 Pad to 16 bytes
 -----
   944 Garlic Message (assumes no bundled leaseSet or keys)
  - 32 session tag
  -  2 tag count
  -  4 payload size
  - 32 payload hash
  -  1 flags
  -  1 clove count
  - 33 clove delivery instructions
       (Tunnel Data Message goes here)
  -  4 clove ID
  -  8 clove expiration
  -  3 clove cert
  -  3 garlic cert
  -  4 garlic ID
  -  8 garlic expiration
 - 135 total overhead
 -----
   809 Data Message
  - 16 I2NP header
  -  4 length
 -----
   789 Gzipped I2NP message
  - 23 Gzip 10 byte header, 5 byte block header, 8 byte trailer (yes we always use gzip, but it
       probably isn't really compressing, just adding the headers and trailer, since
       HTTP Server already compresses, and most P2P files aren't compressible.
       (see client/I2PSessionImpl2.java, util/ReusableGZipOutputStream.java, and the gzip and deflate specs)
 -----
   766
  - 28 Streaming header (22 min) and 6 bytes of options or nacks
 -----
   738 Streaming message size


 FOR TWO TUNNEL MESSAGES:

  2048 2 Tunnel Messages
  - 42 2 Headers
 -----
  2006 Tunnel Payload
  - 50 Fragmented instructions (43 for first + 7 for second)
 -----
  1956 Garlic Message
  - 16 I2NP header
  -  4 length
 -----
  1936 Garlic Message AES payload padded to 16 bytes
  1936
  -  0 Pad to 16 bytes
 -----
  1936 Garlic Message
  - 32 session tag
  -  2 tag count
  -  4 payload size
  - 32 payload hash
  -  1 flags
  -  1 clove count
  - 33 clove delivery instructions
       (Tunnel Data Message goes here)
  -  4 clove ID
  -  8 clove expiration
  -  3 clove cert
  -  3 garlic cert
  -  4 garlic ID
  -  8 garlic expiration
 - 135 total overhead
 -----
  1801 Data Message
  - 16 I2NP header
  -  4 length
 -----
  1781 Gzipped I2NP message
  - 23 Gzip 10 byte header, 5 byte block header, 8 byte trailer
 -----
  1758
  - 28 Streaming header (22 min) and 6 bytes of options or nacks
 -----
  1730 Streaming message size to fit in 2 tunnel messages


 Similarly:
   3 msgs: 2722
   4 msgs: 3714
        Before release 0.6.1.14 this was 4096. From release 0.6.1.14 through release 0.6.4, this was 960. It was claimed in the comment that this fit in a single tunnel message (and the checkin comment says the goal was to increase reliability at the expense of throughput), clearly from the math above that was not correct. (Before 0.6.2, the reply leaseSet was bundled with every message, so it didn't even fit in TWO tunnel messages - more like 2 1/3)

        Now, it's not clear how often we will get the ideal situation (no reply leaseSet bundling, no key bundling, and especially not having a small message ahead of you, which will then cause fragmentation for all subsequent messages until the queue is emptied - BatchedPreprocessor doesn't do reordering, and it isn't clear to me if it could). In particular the initial messages in a new stream are much larger due to the leaseSet and key bundling. But for long-lived streams (like with i2psnark) this should pay dividends. The tunnel.batch* stats should provide some data for test comparisons.

        As MTU and MRU are identical and are negotiated to the lowest value for the two ends, you can't do widespread testing of a higher value. Unless we change to allow MTU and MRU to be different, which would be a pain because it would mess up our buffer scheme. Both 738 and 1730 have been tested to verify that the math above is correct. So let's try 1730 for release 0.6.5. This will allow for 738 testing as well, with i2p.streaming.maxMessageSize=738 (in configadvanced.jsp, or in i2ptunnel, or i2psnark, for example).

        Not that an isolated single packet is very common, but in this case, 960 was 113.3% total overhead. Compared to 738 (38.8% overhead) and 1730 (18.4%).

        See Also:
        Constant Field Values

      • DEFAULT_MAX_MESSAGE_SIZE_RATCHET

        public static final int DEFAULT_MAX_MESSAGE_SIZE_RATCHET
        See analysis in proposal 144
        Since:
        0.9.47
        See Also:
        Constant Field Values

    • Constructor Detail

      • ConnectionOptions

        public ConnectionOptions()
        Sets max buffer size, connect timeout, read timeout, and write timeout from System properties. Does not set local port or remote port.

      • ConnectionOptions

        public ConnectionOptions​(Properties opts)
        Sets max buffer size, connect timeout, read timeout, and write timeout from properties. Does not set local port or remote port. As of 0.9.19, defaults in opts are honored.
        Parameters:
        opts - may be null

      • ConnectionOptions

        public ConnectionOptions​(I2PSocketOptions opts)
        Initializes from System properties then copies over all options.
        Parameters:
        opts - may be null

      • ConnectionOptions

        public ConnectionOptions​(ConnectionOptions opts)
        Initializes from System properties then copies over all options.
        Parameters:
        opts - may be null

    • Method Detail

      • updateAll

        public void updateAll​(ConnectionOptions opts)
        Update everything by copying over from opts
        Parameters:
        opts - non-null
        Since:
        0.9.1

      • setProperties

        public void setProperties​(Properties opts)
        Note: NOT part of the interface As of 0.9.19, defaults in opts are honored.
        Overrides:
        setProperties in class I2PSocketOptionsImpl
        Parameters:
        opts - may be null

      • getConnectDelay

        public int getConnectDelay()
        how long will we wait after instantiating a new con before actually attempting to connect. If this is set to 0, connect ASAP. If it is greater than 0, wait until the output stream is flushed, the buffer fills, or that many milliseconds pass.
        Returns:
        how long to wait before actually attempting to connect

      • setConnectDelay

        public void setConnectDelay​(int delayMs)

      • getRequireFullySigned

        public boolean getRequireFullySigned()
        Do we want all packets in both directions to be signed, or can we deal with signatures on the SYN and FIN packets only? There is no property name defined for this, so it's safe to say this is unused and always false.
        Returns:
        if we want signatures on all packets.

      • setRequireFullySigned

        public void setRequireFullySigned​(boolean sign)
        unused, see above

      • getAnswerPings

        public boolean getAnswerPings()
        Do we respond to a ping?
        Returns:
        if we do

      • setAnswerPings

        public void setAnswerPings​(boolean yes)

      • getEnforceProtocol

        public boolean getEnforceProtocol()
        Do we receive all traffic, or only traffic marked with I2PSession.PROTO_STREAMING (6) ? Default true. If PROTO is enforced, we cannot communicate with destinations earlier than version 0.7.1 (released March 2009), which is when streaming started sending the PROTO_STREAMING indication. Set to true if you are running multiple protocols on a single Destination.
        Returns:
        if we do
        Since:
        0.9.1

      • setEnforceProtocol

        public void setEnforceProtocol​(boolean yes)

      • getDisableRejectLogging

        public boolean getDisableRejectLogging()
        Do we disable connection rejected logging? Default false.
        Returns:
        if we do
        Since:
        0.9.4

      • setDisableRejectLogging

        public void setDisableRejectLogging​(boolean yes)

      • getWindowSize

        public int getWindowSize()
        How many messages will we send before waiting for an ACK?
        Returns:
        Maximum amount of messages that can be in-flight

      • setWindowSize

        public void setWindowSize​(int numMsgs)

      • getReceiveWindow

        @Deprecated
public int getReceiveWindow()
        Deprecated.
        This doesn't appear to be used.
        after how many consecutive messages should we ack?
        Returns:
        receive window size.

      • setReceiveWindow

        public void setReceiveWindow​(int numMsgs)

      • getRTT

        public int getRTT()
        What to set the round trip time estimate to (in milliseconds)
        Returns:
        round trip time estimate in ms

      • getMinRTT

        public int getMinRTT()
        Returns:
        minimum RTT observed over the life of the connection, greater than zero
        Since:
        0.9.46

      • getRTO

        public int getRTO()
        Returns:
        Connection.MIN_RESEND_DELAY to Connection.MAX_RESEND_DELAY

      • getRTTDev

        int getRTTDev()
        used in TCB @since 0.9.8

      • loadFromCache

        void loadFromCache​(int rtt,
                   int rttDev,
                   int wdw)
        Loads options from TCB cache.

      • doubleRTO

        int doubleRTO()
        Double the RTO (after congestion). See RFC 6298 section 5 item 5.5
        Returns:
        new value, Connection.MIN_RESEND_DELAY to Connection.MAX_RESEND_DELAY
        Since:
        0.9.33

      • getRTTTrend

        @Deprecated
public int getRTTTrend()
        Deprecated.
        unused as of 0.9.51
        If we have 3 consecutive rtt increases, we are trending upwards (1), or if we have 3 consecutive rtt decreases, we are trending downwards (-1), else we're stable.
        Returns:
        positive/flat/negative trend in round trip time

      • updateRTT

        public void updateRTT​(int measuredValue)
        Parameters:
        measuredValue - must be positive

      • receivedAck

        public boolean receivedAck()

      • getResendDelay

        public int getResendDelay()
        How long after sending a packet will we wait before resending?
        Returns:
        delay for a retransmission in ms

      • setResendDelay

        public void setResendDelay​(int ms)

      • getSendAckDelay

        public int getSendAckDelay()
        if there are packets we haven't ACKed yet and we don't receive _receiveWindow messages before (_lastSendTime+_sendAckDelay), send an ACK of what we have received so far. Ref: RFC 5681 sec. 4.3, RFC 1122 sec. 4.2.3.3, ticket #2706
        Returns:
        ACK delay in ms

      • setSendAckDelay

        public void setSendAckDelay​(int delayMs)
        Unused except here, so expect the default initial delay of DEFAULT_INITIAL_ACK_DELAY unless set by the user to remain constant. Changing the default is not recommended. Ref: RFC 5681 sec. 4.3, RFC 1122 sec. 4.2.3.3, ticket #2706

      • getMaxMessageSize

        public int getMaxMessageSize()
        What is the largest message we want to send or receive?
        Returns:
        Maximum message size (MTU/MRU)

      • setMaxMessageSize

        public void setMaxMessageSize​(int bytes)

      • getMaxInitialMessageSize

        public int getMaxInitialMessageSize()
        What is the largest message to send in the SYN from Alice to Bob?
        Returns:
        the max
        Since:
        0.9.47

      • setMaxInitialMessageSize

        public void setMaxInitialMessageSize​(int bytes)
        What is the largest message to send in the SYN from Alice to Bob?
        Since:
        0.9.47

      • getProfile

        public int getProfile()
        What profile do we want to use for this connection? TODO: Only bulk is supported so far.
        Returns:
        the profile of the connection.

      • setProfile

        public void setProfile​(int profile)

      • getMaxResends

        public int getMaxResends()
        How many times will we try to send a message before giving up?
        Returns:
        Maximum retrys before failing a sent message.

      • setMaxResends

        public void setMaxResends​(int numSends)

      • getInactivityTimeout

        public int getInactivityTimeout()
        What period of inactivity qualifies as "too long"?
        Returns:
        period of inactivity qualifies as "too long"

      • setInactivityTimeout

        public void setInactivityTimeout​(int timeout)

      • getInactivityAction

        public int getInactivityAction()

      • setInactivityAction

        public void setInactivityAction​(int action)

      • getMaxWindowSize

        public int getMaxWindowSize()

      • setMaxWindowSize

        public void setMaxWindowSize​(int msgs)

      • getInboundBufferSize

        public int getInboundBufferSize()
        how much data are we willing to accept in our buffer?
        Returns:
        size of the buffer used to accept data

      • setInboundBufferSize

        public void setInboundBufferSize​(int bytes)

      • getCongestionAvoidanceGrowthRateFactor

        public int getCongestionAvoidanceGrowthRateFactor()
        When we're in congestion avoidance, we grow the window size at the rate of 1/(windowSize*factor). In standard TCP, window sizes are in bytes, while in I2P, window sizes are in messages, so setting factor=maxMessageSize mimics TCP, but using a smaller factor helps grow a little more rapidly.
        Returns:
        window size to grow by to attempt to avoid congestion.

      • setCongestionAvoidanceGrowthRateFactor

        public void setCongestionAvoidanceGrowthRateFactor​(int factor)

      • getSlowStartGrowthRateFactor

        public int getSlowStartGrowthRateFactor()
        When we're in slow start, we grow the window size at the rate of 1/(factor). In standard TCP, window sizes are in bytes, while in I2P, window sizes are in messages, so setting factor=maxMessageSize mimics TCP, but using a smaller factor helps grow a little more rapidly.
        Returns:
        slow start window size to grow by to attempt to avoid sending many small packets.

      • setSlowStartGrowthRateFactor

        public void setSlowStartGrowthRateFactor​(int factor)

      • getMaxConnsPerMinute

        public int getMaxConnsPerMinute()
        all of these are @since 0.7.14; no public setters

      • getMaxConnsPerHour

        public int getMaxConnsPerHour()

      • getMaxConnsPerDay

        public int getMaxConnsPerDay()

      • getMaxTotalConnsPerMinute

        public int getMaxTotalConnsPerMinute()

      • getMaxTotalConnsPerHour

        public int getMaxTotalConnsPerHour()

      • getMaxTotalConnsPerDay

        public int getMaxTotalConnsPerDay()

      • getMaxConns

        public int getMaxConns()
        Since:
        0.9.3; no public setter

      • isAccessListEnabled

        public boolean isAccessListEnabled()

      • isBlacklistEnabled

        public boolean isBlacklistEnabled()

      • getAccessList

        public Set<Hash> getAccessList()

      • getBlacklist

        public Set<Hash> getBlacklist()

      • getLimitAction

        public String getLimitAction()
        "reset", "drop", "http", or custom string. Default "reset".
        Since:
        0.9.34

      • getTagsToSend

        public int getTagsToSend()
        This option is mostly handled on the router side, but PacketQueue also needs to know, so that when it overrides, it doesn't exceed the setting.
        Since:
        0.9.34

      • getTagThreshold

        public int getTagThreshold()
        This option is mostly handled on the router side, but PacketQueue also needs to know, so that when it overrides, it doesn't exceed the setting.
        Since:
        0.9.34

      • toString

        public String toString()
        doesn't include everything
        Overrides:
        toString in class Object