Package org.klomp.snark

Class PeerState

java.lang.Object
org.klomp.snark.PeerState
All Implemented Interfaces:
DataLoader
class PeerState extends Object implements DataLoader

  • Field Details

    • listener

      final PeerListener listener
      Fixme, used by Peer.disconnect() to get to the coordinator

    • interesting

      volatile boolean interesting

    • choking

      volatile boolean choking

    • interested

      volatile boolean interested

    • choked

      volatile boolean choked

    • bitfield

      BitField bitfield
      the pieces the peer has. locking: this

    • in

      final PeerConnectionIn in

    • out

      final PeerConnectionOut out

    • MIN_PIPELINE

      public static final int MIN_PIPELINE
      Since:
      0.9.47
      See Also:

    • MAX_PIPELINE

      public static final int MAX_PIPELINE
      Since:
      public since 0.9.47
      See Also:

    • PARTSIZE

      public static final int PARTSIZE
      See Also:

  • Constructor Details

  • Method Details

    • keepAliveMessage

      void keepAliveMessage()

    • chokeMessage

      void chokeMessage(boolean choke)

    • interestedMessage

      void interestedMessage(boolean interest)

    • haveMessage

      void haveMessage(int piece)

    • bitfieldMessage

      void bitfieldMessage(byte[] bitmap)

    • requestMessage

      void requestMessage(int piece, int begin, int length)

    • loadData

      public ByteArray loadData(int piece, int begin, int length)
      This is the callback that PeerConnectionOut calls
      Specified by:
      loadData in interface DataLoader
      Returns:
      bytes or null for errors such as not having the piece yet
      Throws:
      RuntimeException - on IOE getting the data
      Since:
      0.8.2

    • uploaded

      void uploaded(int size)
      Called when some bytes have left the outgoing connection. XXX - Should indicate whether it was a real piece or overhead.

    • pieceMessage

      void pieceMessage(Request req)
      Called when a full chunk (i.e. a piece message) has been received by PeerConnectionIn. This may block quite a while if it is the last chunk for a piece, as it calls the listener, who stores the piece and then calls havePiece for every peer on the torrent (including us).

    • getOutstandingRequest

      Request getOutstandingRequest(int piece, int begin, int length)
      Called when a piece message is being processed by the incoming connection. That is, when the header of the piece message was received. Returns null when there was no such request. It also requeues/sends requests when it thinks that they must have been lost.

    • returnPartialPieces

      List<Request> returnPartialPieces()
      Get partial pieces, give them back to PeerCoordinator. Clears the request queue.
      Returns:
      List of PartialPieces, even those with an offset == 0, or empty list
      Since:
      0.8.2

    • cancelMessage

      void cancelMessage(int piece, int begin, int length)

    • extensionMessage

      void extensionMessage(int id, byte[] bs)
      Since:
      0.8.2

    • setMetaInfo

      public void setMetaInfo(MetaInfo meta)
      Switch from magnet mode to normal mode. If we already have the metainfo, this does nothing.
      Parameters:
      meta - non-null
      Since:
      0.8.4

    • portMessage

      void portMessage(int port)
      Unused
      Since:
      0.8.4

    • suggestMessage

      void suggestMessage(int piece)
      BEP 6 Treated as "have" for now
      Since:
      0.9.21

    • haveMessage

      void haveMessage(boolean isAll)
      BEP 6
      Parameters:
      isAll - true for have_all, false for have_none
      Since:
      0.9.21

    • rejectMessage

      void rejectMessage(int piece, int begin, int length)
      BEP 6 If the peer rejects lower chunks but not higher ones, thus creating holes, we won't figure it out and the piece will fail, since we don't currently keep a chunk bitmap in PartialPiece. As long as the peer rejects all the chunks, or rejects only the last chunks, no holes are created and we will be fine. The reject messages may be in any order, just don't make a hole when it's over.
      Since:
      0.9.21

    • allowedFastMessage

      void allowedFastMessage(int piece)
      BEP 6 Ignored for now
      Since:
      0.9.21

    • unknownMessage

      void unknownMessage(int type, byte[] bs)

    • havePiece

      void havePiece(int piece)
      We now have this piece. Tell the peer and cancel any requests for the piece.

    • cancelPiece

      void cancelPiece(int piece)
      Tell the other side that we are no longer interested in any of the outstanding requests (if any) for this piece.
      Since:
      0.8.1

    • isRequesting

      @Deprecated boolean isRequesting(int piece)
      Deprecated.
      deadlocks
      Are we currently requesting the piece?
      Since:
      0.8.1

    • addRequest

      void addRequest()
      Adds a new request to the outstanding requests list. Then send interested if we weren't. Then send new requests if not choked. If nothing to request, send not interested if we were. This is called from several places: 
         By getOustandingRequest() when the first part of a chunk comes in
   By havePiece() when somebody got a new piece completed
   By chokeMessage() when we receive an unchoke
   By setInteresting() when we are now interested
   By PeerCoordinator.updatePiecePriorities()

    • setInteresting

      void setInteresting(boolean interest)

    • setChoking

      void setChoking(boolean choke)

    • keepAlive

      void keepAlive()

    • retransmitRequests

      void retransmitRequests()

    • getRequests

      String getRequests()
      debug
      Returns:
      string or null
      Since:
      0.8.1