net.i2p.client.streaming
Class ConnectionDataReceiver

java.lang.Object
  extended by net.i2p.client.streaming.ConnectionDataReceiver
All Implemented Interfaces:
MessageOutputStream.DataReceiver

 class ConnectionDataReceiver
extends java.lang.Object
implements MessageOutputStream.DataReceiver

Receive data from the MessageOutputStream, build a packet, and send it through a connection. The write calls on this do NOT block, but they also do not necessary imply immediate delivery, or even the generation of a new packet. This class is the only one that builds useful outbound Packet objects.


Constructor Summary
ConnectionDataReceiver(I2PAppContext ctx, Connection con)
           
 
Method Summary
(package private)  void destroy()
           
 PacketLocal send(byte[] buf, int off, int size)
          Send some data through the connection, attaching any appropriate flags onto the packet.
 PacketLocal send(byte[] buf, int off, int size, boolean forceIncrement)
           
 MessageOutputStream.WriteStatus writeData(byte[] buf, int off, int size)
          Send some data through the connection, or if there is no new data, this may generate a packet with a plain ACK/NACK or CLOSE, or nothing whatsoever if there's nothing new to send.
 boolean writeInProcess()
          This tells the flusher in MessageOutputStream whether to flush.
 
Methods inherited from class java.lang.Object
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait
 

Constructor Detail

ConnectionDataReceiver

public ConnectionDataReceiver(I2PAppContext ctx,
                              Connection con)
Method Detail

writeInProcess

public boolean writeInProcess()
This tells the flusher in MessageOutputStream whether to flush. It won't flush if this returns true. It was: return con.getUnackedPacketsSent() > 0 (i.e. Nagle) But then, for data that fills more than one packet, the last part of the data isn't sent until all the previous packets are acked. Which is very slow. The poor interaction of Nagle and Delayed Acknowledgements is well-documented. So let's send data along unless the outbound window is full. (i.e. no-Nagle or TCP_NODELAY) Probably should have a configuration option for this.

Specified by:
writeInProcess in interface MessageOutputStream.DataReceiver
Returns:
!flush

writeData

public MessageOutputStream.WriteStatus writeData(byte[] buf,
                                                 int off,
                                                 int size)
Send some data through the connection, or if there is no new data, this may generate a packet with a plain ACK/NACK or CLOSE, or nothing whatsoever if there's nothing new to send.

Specified by:
writeData in interface MessageOutputStream.DataReceiver
Parameters:
buf - data to be sent - may be null
off - offset into the buffer to start writing from
size - how many bytes of the buffer to write (may be 0)
Returns:
an object to allow optional blocking for data acceptance or delivery.

send

public PacketLocal send(byte[] buf,
                        int off,
                        int size)
Send some data through the connection, attaching any appropriate flags onto the packet.

Parameters:
buf - data to be sent - may be null
off - offset into the buffer to start writing from
size - how many bytes of the buffer to write (may be 0)
Returns:
the packet sent, or null if the connection died

send

public PacketLocal send(byte[] buf,
                        int off,
                        int size,
                        boolean forceIncrement)
Parameters:
buf - data to be sent - may be null
off - offset into the buffer to start writing from
size - how many bytes of the buffer to write (may be 0)
forceIncrement - even if the buffer is empty, increment the packetId so we get an ACK back
Returns:
the packet sent

destroy

void destroy()