Package net.i2p.client.streaming.impl


package net.i2p.client.streaming.impl

Implementation of a TCP-like (reliable, authenticated, in order) set of sockets for communicating over the IP-like (unreliable, unauthenticated, unordered) I2P messages. This is the streaming implementation (moved for ticket #1135 to here). For the API (which you probably want), see ministreaming. Clients should not need to access anything in this package directly. Use the interfaces and factory in net.i2p.streaming. Note that this class is split across two jars, streaming.jar and ministreaming.jar. The interfaces and some code are in ministreaming.jar, but the real work gets done in streaming.jar. Clients must have both jars in their classpath. Most clients will require (only) streaming.jar, ministreaming.jar, and i2p.jar in their classpath to communicate with the router.

  • Class
    Description
    Maintain the state controlling a streaming connection between two destinations.
    Receive data from the MessageOutputStream, build a packet, and send it through a connection.
    Receive new connection attempts Use a bounded queue to limit the damage from SYN floods, router overload, or a slow client
    Coordinate all of the connections for a single local destination.
    The callback interface for a pong.
    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
    Receive a packet for a particular connection - placing the data onto the queue, marking packets as acked, updating various fields, etc.
    Count how often we have received an incoming connection This offers basic DOS protection but is not a complete solution.
    Bridge to allow accepting new connections
    Bridge between the full streaming lib and the I2PSocket API
    Centralize the coordination and multiplexing of the local client's streaming.
    Define the configuration for streaming and verifying data on the socket.
    Receive raw information from the I2PSession and turn it into Packets, if we can.
    Stream that can be given messages out of order yet present them in order.
    A stream that we can shove data into that fires off those bytes on flush or when the buffer is full.
    Define a component to receive data flushed from this stream
    Define a way to detect the status of a write
    This contains solely the data that goes out on the wire, including the local and remote port which is embedded in the I2CP overhead, not in the packet itself.
    receive a packet and dispatch it correctly to the connection specified, the server socket, or queue a reply RST packet.
    This is the class used for outbound packets.
    Queue out packets to be sent through the session.
    Write a standard pcap file with a "TCP" packet that can be analyzed with standard tools such as wireshark.
    Per-destination timer
    Examine a connection's state and pick the right scheduler for it.
    Scheduler used for after both sides have had their close packets ACKed, but the final timeout hasn't passed.
    Scheduler used for after both SYNs have been ACKed and both sides have closed the stream, but either we haven't ACKed their close or they haven't ACKed ours.
    Scheduler used for after our SYN has been sent and ACKed but one (or more) sides haven't closed the stream yet.
    Scheduler used once we've sent our SYN but it hasn't been ACKed yet.
    Scheduler used for after the final timeout has passed or the connection was reset.
    Scheduler used after we've locally done a hard disconnect, but the final timeout hasn't passed.
    Base scheduler
    Scheduler used for locally created connections where we have not yet sent the initial SYN packet.
    Scheduler used after receiving an inbound connection but before we have sent our own SYN.
    A Westwood+ bandwidth estimator with a first stage anti-aliasing low pass filter based on RTT, and the time-varying Westwood filter based on inter-arrival time.
    Bridge to I2PServerSocket.
    Bridge to I2PSocket.
    Coordinates what we do 'next'.
    Share important TCP Control Block parameters across Connections to the same remote peer.
    We attempted to have more open streams than we are willing to put up with