I readded the substractions from the constructor and is working again just fine. It is some Java thing on which we need to research on ...
This one is better, sorry
still working, this commit is just in case
After a silly hour of fighting with sendBitField() method, finding the best approach not to screw it up... I won. I have to peers talking to each other... the receiving peer is indeed receving handshake, unchocking, bitfield and requesting pieces upong verifying everything is correct. Now I will FINALLY focus in the sendPieces and stuff methods.
Fixed the PeerListener switch flag 6 for request received... it was reading an extra byte. Got rid of it... and disposed the body.
We are offically uploading pieces! As it really should do it? stay put...
Dropping connection if requested piece length is greater than maximum.
Out-of-bounds error checking on peer input for haveReceived().
Fixed peer number offset on "connect" command.
I think we'd best return at this point!
This takes care of the long wait for an active command prompt.
Added print confirmation when piece has been sent.
Arranged for tracker interval to be updated and saved.
Still have not implemented its use in timing tracker refreshes.
Made print announcement when client uploads a piece.  I wonder if we
should verify whether the receiver sends a have message following this.
Also made revisions based on Ike's recommendations.  Thanks, Isaac.
Added try/catch block to Utilities.decodeInterval()
Tracker-refresh_timing_automation.txt

  I cannot seem to push from my Linux Pentium III box, so here is what I have.  
  This is meant to track the tracker refresh timing as per the interval mapped in the tracker responses.
Cleaned and polished. I also added some lines to peer listener such that it will not accept pieces anymore if the file is complete.
More polishing, gonna generate javadoc in next commit
All javadoc documented and added to doc/Project 1 Documentation
This should take care of the tracker refreshing rate, as per the assigned
requirements.
Decided to comment out the error message when min_interval is not set,
because this seems to be the normal situation, to avoid lots of the
same repeated error messages.
Decided that 2*min_interval is safer timing than min_interval, if
specified.
This takes care of notifying tracker that client has reached the "stopped"
event.