[bittorrent] compact ip problem

Dazen D dazensix at gmail.com
Thu Aug 23 01:04:10 EDT 2007


Alan, no, i didn't type it. I got it from a very popular tracker.

I just captured some responses from the tracker and
this is what i've got:

- Using uTorrent:

d8:completei2e10:downloadedi6e10:incompletei0e8:intervali2164e12:min
intervali2100e5:peerslee˜å m—'ë¼4,±	à'ìâ6œÆ´Øòçf"'ÐÖ

which is precisely what you call the incorrect format. what
happens is that the tracker makes a no peers response and
appends the peers in the end.

- Using Azureus:

d8:completei1e10:downloadedi5e10:incompletei0e8:intervali2279e12:min
intervali2100e5:peers6:T›zCÂ}e

now the tracker sends the specification compliant response.

Apparently the tracker sends different formats, according to
the client. I tested using my code and in fact uTorrent supports this
alternate format, while Azureus don't. I just don't see the
purpose of this alternate format, as it has no apparent benefit.

On 8/23/07, Alan McGovern <alan.mcgovern at gmail.com> wrote:
> From the spec:
>
> > compact: Indicates the client accepts a compact response. The peers list
> is replaced by a peers string with 6 bytes per peer. The first four bytes
> are the host (in network byte order), the last two bytes are the port (again
> in network byte order).
> >
>
>
> In other words:
> Correct:
> d8:intervali1800e8:completei1e10:incompletei1e5:peers6:XXXXYYeIncorrect:
> d8:intervali1800e8:completei1e10:incompletei1e5:peerspeersleeXXXXYY
>
> Also, i don't quite understand what's going on in the second one... i assume
> you typo'ed it. If a tracker is returning you a response other than one
> which defined in the spec, you should file a bug report with that tracker.
>
> Alan.
>
>
> On 8/22/07, Dazen D <dazensix at gmail.com> wrote:
> > folks, i have to apologize for that, i was checking the code
> > and just found the problem, and it has nothing to do with
> > the problem i brought to the list. but certainly the suggestions
> > helped me to enrich my implementation. it's working
> > properly now.
> >
> > but i think that it would be nice to discuss one thing that
> > i pointed in the original mail. i realized that some trackers
> > respond differently when sending compact ips. some use the format:
> >
> >
> d8:intervali1800e8:completei1e10:incompletei1e5:peers6:XXXXYYe
> >
> > (where "XXXX" are the IP bytes and "YY" the port bytes.)
> >
> > others use:
> >
> >
> d8:intervali1800e8:completei1e10:incompletei1e5:peerspeersleeXXXXYY
> >
> > does anyone know which format is preferable?
> >
> >
> > Ryan, thanks for your reply. In fact, although it's a http
> > response, it doesn't matter what you send. if you set
> > the response to text plain, for example, you can send
> > anything. That's the right way to respond to the client,
> > for example.
> >
> >
> > > On 8/23/07, Ryan Walklin <ryanwalklin at gmail.com> wrote:
> > > > Hi,
> > > >
> > > > I'm unfamiliar with Java's network code, but surely you want to write
> the
> > > > response to the client with a raw data socket, rather than with HTTP?
> The
> > > > peer wire protocol is used instead of HTTP, rather than on top of it.
> You
> > > > only use HTTP when communicating with trackers. In any case, you
> should
> > > > probably be sending octet-stream rather than text/plain.
> > > >
> > > > Apologies if the above is incorrect, I don't know Java well, and the
> methods
> > > > for sending below might not be introducing HTTP headers.
> > > >
> > > > Regards,
> > > >
> > > > Ryan
> > > >
> > > >
> > > > On 8/23/07, Dazen D < dazensix at gmail.com> wrote:
> > > > > Ben, Andre, thanks for your replies.
> > > > >
> > > > > Ben, inetAddress.getAddress() returns a byte array,
> > > > > which is expressed by "byte[]". I'll check the
> > > > > endianness of the data, but i think that java deals
> > > > > with that using different types (short, int, long, etc).
> > > > >
> > > > > Andre, i omitted some portions of the code, and didn't
> > > > > realize that it made the code confuse. The full code
> > > > > is:
> > > > >
> > > > >     public byte[] getCompactIP(String ip, int port) {
> > > > >
> > > > >         byte[] rawAddress = null;
> > > > >         try {
> > > > >           InetAddress inetAddress = InetAddress.getByName(ip);
> > > > >           rawAddress = inetAddress.getAddress();
> > > > >         }
> > > > >         catch(UnknownHostException e) {
> > > > >           return null;
> > > > >         }
> > > > >         if (rawAddress.length == 4) {
> > > > >             byte[] compactIP = new byte[6];
> > > > >             for (int i = 0; i < 4; i++) {
> > > > >                 compactIP[i] = rawAddress[i];
> > > > >             }
> > > > >             compactIP[4] = (byte)(port >> 8);
> > > > >             compactIP[5] = (byte)(port & 0xff);
> > > > >
> > > > >             return compactIP;
> > > > >         }
> > > > >         return null;
> > > > >     }
> > > > >
> > > > >
> > > > > I tried your suggestion and changed the bitwise operator
> > > > > but the outputed bytes didn't change, and the client
> > > > > continues to not recognize the data. For example, for
> > > > > port 28387 the bytes generated are "nã", in both cases.
> > > > >
> > > > > Another thing, when i send the response to the client
> > > > > i set the response using:
> > > > >
> > > > >     OutputStream outputStream =
> > > > httpServletResponse.getOutputStream ();
> > > > >
> httpServletResponse.setContentType("text/plain");
> > > > >     (write bytes to output)
> > > > >
> > > > > Should the content type be different?
> > > > >
> > > > > Thanks again.
> > > > >
> > > > >
> > > > > On 8/22/07, André <ghost.ued at gmail.com> wrote:
> > > > > > "You want to save each section of the
> > > > > > IP address as a unsigned 8 bit integer. "
> > > > > >
> > > > > > actually, in a 32 bit integer xD
> > > > > >
> > > > > > Dazen, the operator you need is not >>. It's >>> .
> > > > > >
> > > > > >  Look for java bitwise operators, and you will see the difference.
> > > > > >
> > > > > >
> > > > > > i did not understand your code, but the size seems right: each
> pair Ip
> > > > > > and port uses 6 bytes.
> > > > > >
> > > > > > here is my code:
> > > > > >
> > > > > > byte[] ipembytes =InetAddress.getByName(ip);
> > > > > >
> > > > > >                       peerByteResponse[ actualLength] =
> ipembytes[0];
> > > > > >                       peerByteResponse[ actualLength+1] =
> ipembytes[1] ;
> > > > > >                       peerByteResponse[ actualLength+2] =
> ipembytes[2] ;
> > > > > >                       peerByteResponse[ actualLength+3] =
> ipembytes[3] ;
> > > > > >
> peerByteResponse[actualLength+4]=
> > > > (byte)(port >>>8);
> > > > > >
> peerByteResponse[actualLength+5]=
> > > > (byte)port;
> > > > > >
> > > > > > (peerByteResponse is a bytre array with the peers string)
> > > > > > _______________________________________________
> > > > > > BitTorrent mailing list
> > > > > > BitTorrent at lists.ibiblio.org
> > > > > >
> http://lists.ibiblio.org/mailman/listinfo/bittorrent
> > > > > >
> > > > > _______________________________________________
> > > > > BitTorrent mailing list
> > > > > BitTorrent at lists.ibiblio.org
> > > > >
> http://lists.ibiblio.org/mailman/listinfo/bittorrent
> > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > BitTorrent mailing list
> > > > BitTorrent at lists.ibiblio.org
> > > > http://lists.ibiblio.org/mailman/listinfo/bittorrent
> > > >
> > > >
> > >
> > _______________________________________________
> > BitTorrent mailing list
> > BitTorrent at lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/bittorrent
> >
>
>


More information about the BitTorrent mailing list