libbt-devel

[Libbt-devel] added header files that will be installed

[Alien <ali...@us...>]

I added 2 header files that'll be installed together with the library.

these are the header files that'll have to be used by the frontend to contr=
ol=20
the library.

ALSO!: these header files MUST be used by the library itself as well, so no=
=20
future conflicts arise!
=2D-=20
Alien is my name and head-biting is my game.

Re: [Libbt-devel] added header files that will be installed

[Alien <ali...@us...>]

Op vrijdag 11 februari 2005 09:00, schreef Alien:
> I added 2 header files that'll be installed together with the library.
>
> these are the header files that'll have to be used by the frontend to
> control the library.
>
> ALSO!: these header files MUST be used by the library itself as well, so =
no
> future conflicts arise!


forgot to mention that it's bt.h and bttypes.h and will be installed in=20
${include}/bt/

which means that applications will have:

#include <bt/bt.h>

in their header includes.

bt.h also includes bttypes.h so it's easier not to make mistakes
=2D-=20
Alien is my name and head-biting is my game.

Re: [Libbt-devel] added header files that will be installed

[Peter S. <stu...@cd...>]

On Fri, Feb 11, 2005 at 09:09:28AM +0100, Alien wrote:
> bt.h also includes bttypes.h so it's easier not to make mistakes

From btTorrent:

    int listenport;             /* is this required??? */

No, listenport is not required, if we're going to do the networking
in libbt I strongly suggest that we only use a single port per
application, and by default one in the dynamic port range as defined
by IANA, 49152 through 65536. Start from the bottom and try
allocating upwards.

The common 6881 port and thereabout are listed as:
--8<-- http://www.iana.org/assignments/port-numbers
#               6851-6887   Unassigned
muse            6888/tcp    MUSE
muse            6888/udp    MUSE
#                           Muse Communications Corporation
#                           <ho...@mu...>
#               6889-6960   Unassigned
-->8--

..and hence not really a good fit. Also, there's no telling how many
bt listeners may be active on a single host, so unless there's that
global system mentioned before bt really shouldn't be allocated just
a single port.

And most importantly a dynamic port fits the application. This is not
a server that peers will try to connect blindly to as a result of a
user command, instead peer lists come from the tracker and so ports
do not matter.

--8<-- docs/protocol.txt, about communication between peers
Next comes the 20 byte sha1 hash of the bencoded form of the 'info'
value from the metainfo file. (This is the same value which is
announced as info_hash to the tracker, only here it's raw instead of
quoted here). If both sides don't send the same value, they sever the
connection. The one possible exception is if a downloader wants to do
multiple downloads over a single port, they may wait for incoming
connections to give a download hash first, and respond with the same
one if it's in their list.
-->8--

This sounds good to me.


//Peter

Re: [Libbt-devel] added header files that will be installed

[Elliott M. <eh...@m5...>]

>From: Peter Stuge <stu...@cd...>
> On Fri, Feb 11, 2005 at 09:09:28AM +0100, Alien wrote:
> > bt.h also includes bttypes.h so it's easier not to make mistakes
> 
> >From btTorrent:
> 
>     int listenport;             /* is this required??? */
> 
> No, listenport is not required, if we're going to do the networking
> in libbt I strongly suggest that we only use a single port per
> application, and by default one in the dynamic port range as defined
> by IANA, 49152 through 65536. Start from the bottom and try
> allocating upwards.

It is standard practice for BT clients to start at 6881 and go up as
high as 6889. This is semi-silly, but it does make it easier to implement
MitM caches if so desired.

Failing that, taking whichever port the OS gives to you is standard
practice. This typically starts at 1024 and goes upwards as various
programs use temporary ports.


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \   (    |         EH...@gr... PGP 8881EF59         |    )   /
  \_  \   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
    \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/

Re: [Libbt-devel] added header files that will be installed

[Tyler M. <ty...@Ac...>]

Elliott Mitchell <eh...@m5...> wrote:
> > No, listenport is not required, if we're going to do the networking
> > in libbt I strongly suggest that we only use a single port per
> > application, and by default one in the dynamic port range as defined
> > by IANA, 49152 through 65536. Start from the bottom and try
> > allocating upwards.
> It is standard practice for BT clients to start at 6881 and go up as
> high as 6889. This is semi-silly, but it does make it easier to implement
> MitM caches if so desired.

	I vote for *NOT* using those ports by default. Bram Cohen has said
that it was a bad idea to begin with, azureus and other clients allocate in
the IANA range now, and some ISPs have begun filtering or severely
throttling ports in the "standard" BT range.

	That said, I think it would be nice to give the application the
chance to decide what port it wants to listen on, and maybe even pass it's
own socket fd to the library and say "here, use this"... but if it doesnt
take that chance, proceed with allocating a random port either by not
specifying one to bind, or by picking one in the IANA range that's
available.

	- Tyler

Re: [Libbt-devel] added header files that will be installed

[Nathan F. <zi...@gm...>]

I think it would be best for the user to be able to set the port (and
use this one port for all torrent transfers) so that users behind
firewalls can forward the port. If not a single port than atleast a
range that can also be forwarded.

--Nate

On Fri, 11 Feb 2005 13:47:34 -0800, Tyler MacDonald
<ty...@ac...> wrote:
> Elliott Mitchell <eh...@m5...> wrote:
> > > No, listenport is not required, if we're going to do the networking
> > > in libbt I strongly suggest that we only use a single port per
> > > application, and by default one in the dynamic port range as defined
> > > by IANA, 49152 through 65536. Start from the bottom and try
> > > allocating upwards.
> > It is standard practice for BT clients to start at 6881 and go up as
> > high as 6889. This is semi-silly, but it does make it easier to implement
> > MitM caches if so desired.
> 
>        I vote for *NOT* using those ports by default. Bram Cohen has said
> that it was a bad idea to begin with, azureus and other clients allocate in
> the IANA range now, and some ISPs have begun filtering or severely
> throttling ports in the "standard" BT range.
> 
>        That said, I think it would be nice to give the application the
> chance to decide what port it wants to listen on, and maybe even pass it's
> own socket fd to the library and say "here, use this"... but if it doesnt
> take that chance, proceed with allocating a random port either by not
> specifying one to bind, or by picking one in the IANA range that's
> available.
> 
>        - Tyler
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Libbt-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libbt-devel
>

Re: [Libbt-devel] the port [was: header files]

[Peter S. <stu...@cd...>]

On Fri, Feb 11, 2005 at 01:38:11PM -0800, Elliott Mitchell wrote:
> >From: Peter Stuge <stu...@cd...>
> > 
> > No, listenport is not required, if we're going to do the networking
> > in libbt I strongly suggest that we only use a single port per
> > application, and by default one in the dynamic port range as defined
> > by IANA, 49152 through 65536. Start from the bottom and try
> > allocating upwards.
> 
> It is standard practice for BT clients to start at 6881 and go up as
> high as 6889. This is semi-silly, but it does make it easier to
> implement MitM caches if so desired.

It's completely silly, since some of those ports are reserved by IANA
and some are unassigned. In either case it is really inappropriate to
use them.


> Failing that, taking whichever port the OS gives to you is standard
> practice. This typically starts at 1024 and goes upwards as various
> programs use temporary ports.

For outgoing connections, yes. For incoming connections, no, not in
Linux at least. I just tried;

stuge@carepad4 ~/a $ cat a.c
#include <sys/socket.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>
#include <netinet/in.h>

int main() {
  int s,i;  
  struct sockaddr_in sa;
  struct sockaddr *sap=(struct sockaddr *)&sa;
  s=socket(PF_INET,SOCK_STREAM,0);
  listen(s,5);  
  getsockname(s,sap,&i);
  printf("got ip %s port
%d\n",inet_ntoa(sa.sin_addr),ntohs(sa.sin_port));
  close(s);
  return 0;
}

--8<-- ip(7)
When listen(2) or connect(2) are called on a unbound socket the
socket is automatically bound to a random free port with the local
address set to INADDR_ANY.
-->8--

stuge@carepad4 ~/a $ ./a
got ip 0.0.0.0 port 57839

If I run it over and over again it steers clear of ports used by
netfilter:

stuge@carepad4 ~/a $ while :;do ./a;done
[..]
got ip 0.0.0.0 port 60999
got ip 0.0.0.0 port 61000
got ip 0.0.0.0 port 32768
got ip 0.0.0.0 port 32769


On Fri, Feb 11, 2005 at 01:47:34PM -0800, Tyler MacDonald wrote:
> Elliott Mitchell <eh...@m5...> wrote:
> > It is standard practice for BT clients to start at 6881 and go up as
> > high as 6889. This is semi-silly, but it does make it easier to
> > implement MitM caches if so desired.
> 
> 	I vote for *NOT* using those ports by default. Bram Cohen has
> said that it was a bad idea to begin with,

It was.


> 	That said, I think it would be nice to give the application
> the chance to decide what port it wants to listen on, and maybe even
> pass it's own socket fd to the library and say "here, use this"...
> but if it doesnt take that chance, proceed with allocating a random
> port either by not specifying one to bind, or by picking one in the
> IANA range that's available.

This is just a few lines of code we're discussing, but I still think
it's important to get right.

If user specifies port, try to use that. If it fails, give up and
complain to user.

If there's no user setting, try listen() and check that we got a port
in the dynamic range. Linux can fail here, as shown above. If not,
close the socket and make a new one. (How will this affect the IP
stack? This isn't playing really nice with it, I can imagine that
Windows would get upset by this kind of thing.)

If there's still no good socket to accept() on, try bind()ing each
port in the dynamic range.

If that fails, give up and complain to user.


On Fri, Feb 11, 2005 at 05:45:48PM -0500, Nathan Ford wrote:
> I think it would be best for the user to be able to set the port
> (and use this one port for all torrent transfers) so that users
> behind firewalls can forward the port.

Fully agreed. I need that. User setting will always have precedence.


> If not a single port than atleast a range that can also be
> forwarded.

There is no reason to use more than one port.


//Peter

Re: [Libbt-devel] the port [was: header files]

[Alien <ali...@us...>]

Op zaterdag 12 februari 2005 15:15, schreef Peter Stuge:
> > If not a single port than atleast a range that can also be
> > forwarded.
>
> There is no reason to use more than one port.

and a user defined range to pick one out at random? i'm just saying that th=
e=20
user might want to have 567-574 and have 4 appl using libbt or an appl usin=
g=20
4 instances of libbt just want it?

Re: [Libbt-devel] the port [was: header files]

[Peter S. <stu...@cd...>]

On Sun, Feb 13, 2005 at 11:31:27PM +0100, Alien wrote:
> Op zaterdag 12 februari 2005 15:15, schreef Peter Stuge:
> > > If not a single port than atleast a range that can also be
> > > forwarded.
> >
> > There is no reason to use more than one port.
> 
> and a user defined range to pick one out at random? i'm just saying
> that the user might want to have 567-574 and have 4 appl using
> libbt or an appl using 4 instances of libbt just want it?

Fair enough. Four applications with libbt need separate ports, but
then the port is a setting in the application rather than libbt. And
if there is no setting, just use any free dynamic port. As for the
application, it can either inform libbt about the setting, or do the
work on it's own and provide libbt a socket after bind() and
listen().

IMHO, an application shouldn't ever need to and possibly not even be
able to "start" more than one instance of libbt, this is one reason,
there are probably more.


//Peter

Re: [Libbt-devel] the port [was: header files]

[Alien <ali...@us...>]

Op maandag 14 februari 2005 00:55, schreef Peter Stuge:
> On Sun, Feb 13, 2005 at 11:31:27PM +0100, Alien wrote:
> > Op zaterdag 12 februari 2005 15:15, schreef Peter Stuge:
> > > > If not a single port than atleast a range that can also be
> > > > forwarded.
> > >
> > > There is no reason to use more than one port.
> >
> > and a user defined range to pick one out at random? i'm just saying
> > that the user might want to have 567-574 and have 4 appl using
> > libbt or an appl using 4 instances of libbt just want it?
>
> Fair enough. Four applications with libbt need separate ports, but
> then the port is a setting in the application rather than libbt. And
> if there is no setting, just use any free dynamic port. As for the
> application, it can either inform libbt about the setting, or do the
> work on it's own and provide libbt a socket after bind() and
> listen().
>
> IMHO, an application shouldn't ever need to and possibly not even be
> able to "start" more than one instance of libbt, this is one reason,
> there are probably more.

you have a point, but i'm just saying that if libbt can accept a port, it=20
could very well even accept a port range, where it randomly can choose from=
=2E=20
of course, the library should get everything do everything on one port.

Re: [7] [Libbt-devel] added header files that will be installed

[Kevin S. <ke...@an...>]

Peter Stuge wrote:

>On Fri, Feb 11, 2005 at 09:09:28AM +0100, Alien wrote:
>  
>
>>bt.h also includes bttypes.h so it's easier not to make mistakes
>>    
>>
>
>>From btTorrent:
>
>    int listenport;             /* is this required??? */
>
>No, listenport is not required, if we're going to do the networking
>in libbt I strongly suggest that we only use a single port per
>application, and by default one in the dynamic port range as defined
>by IANA, 49152 through 65536. Start from the bottom and try
>allocating upwards.
>
>  
>
People who operate firewalls generally prefer to know what it is that 
they are opening up a hole for.  Follow the protocol spec, use the 
specified port range.

>And most importantly a dynamic port fits the application. This is not
>a server that peers will try to connect blindly to as a result of a
>user command, instead peer lists come from the tracker and so ports
>do not matter.
>
>  
>
Bram has a lot of experience with actual deployments.  Pretend that he 
knows what he is doing.

>--8<-- docs/protocol.txt, about communication between peers
>Next comes the 20 byte sha1 hash of the bencoded form of the 'info'
>value from the metainfo file. (This is the same value which is
>announced as info_hash to the tracker, only here it's raw instead of
>quoted here). If both sides don't send the same value, they sever the
>connection. The one possible exception is if a downloader wants to do
>multiple downloads over a single port, they may wait for incoming
>connections to give a download hash first, and respond with the same
>one if it's in their list.
>-->8--
>
>This sounds good to me.
>
>
>//Peter
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Libbt-devel mailing list
>Lib...@li...
>https://lists.sourceforge.net/lists/listinfo/libbt-devel
>  
>

Re: [7] [Libbt-devel] added header files that will be installed

[Peter S. <stu...@cd...>]

On Tue, Mar 08, 2005 at 11:35:31PM -0800, Kevin Smathers wrote:
> Peter Stuge wrote:
> >
> >No, listenport is not required, if we're going to do the networking
> >in libbt I strongly suggest that we only use a single port per
> >application, and by default one in the dynamic port range as defined
> >by IANA, 49152 through 65536. Start from the bottom and try
> >allocating upwards.
> 
> People who operate firewalls generally prefer to know what it is
> that they are opening up a hole for.

We know that we can't tell anything about the traffic we're opening
holes for unless we actually inspect it. A simple stateful packet
filter will not and can not know what the application is doing and
assuming that a certain port only carries certain traffic is silly.


> Follow the protocol spec, use the specified port range.

I prefer to follow IANA and use a non-reserved port.

Plus;

> >And most importantly a dynamic port fits the application. This is
> >not a server that peers will try to connect blindly to as a result
> >of a user command, instead peer lists come from the tracker and so
> >ports do not matter.
> 
> Bram has a lot of experience with actual deployments.  Pretend that
> he knows what he is doing.

You can't seriously mean that arbitrary allocation of ports in the
IANA reserved range by individual software manufacturers is a good
thing?  Further, someone mentioned a post by Bram in which he
recognized that this particular part of the protocol documentation
was unfortunate. It's a non-issue AFAICS, since all clients always
tell the tracker which port they're using.

As for firewalls, that's another issue, I think the best solution
would be for Bram to get a port allocated by IANA and then all BT
software could use that as the default. Until then, nothing we do
in libbt will be of much help for firewall operators..

Plus; users should be able to pick the port if they want.


//Peter

Re: [7] [Libbt-devel] added header files that will be installed

[Kevin S. <ke...@an...>]

Peter Stuge wrote:

>On Tue, Mar 08, 2005 at 11:35:31PM -0800, Kevin Smathers wrote:
>  
>
>>Peter Stuge wrote:
>>    
>>
>>>No, listenport is not required, if we're going to do the networking
>>>in libbt I strongly suggest that we only use a single port per
>>>application, and by default one in the dynamic port range as defined
>>>by IANA, 49152 through 65536. Start from the bottom and try
>>>allocating upwards.
>>>      
>>>
>>People who operate firewalls generally prefer to know what it is
>>that they are opening up a hole for.
>>    
>>
>
>We know that we can't tell anything about the traffic we're opening
>holes for unless we actually inspect it. A simple stateful packet
>filter will not and can not know what the application is doing and
>assuming that a certain port only carries certain traffic is silly.
>
>  
>
The way that the protocol specification reads, it is difficult to 
imagine an effective proxy for BitTorrent.  It really is designed solely 
as a peer to peer protocol.  Traversing a NAT gateway and firewall by 
opening up the appropriate port is the most widely supported way to 
connect on a peer to peer level.  A specialized proxy or NAT plug-in, if 
an appropriate one is constructed, would improve security by adding a 
boundary layer, but experience with SIP and other gateway protocols 
tells me that even hard pushing by well monied champions can fail to 
penetrate deeply into the router market, and BitTorrent is grass-roots.  
If you want to pursue it then more power to you, but I have different 
priorities.

>>>And most importantly a dynamic port fits the application. This is
>>>not a server that peers will try to connect blindly to as a result
>>>of a user command, instead peer lists come from the tracker and so
>>>ports do not matter.
>>>      
>>>
>>Bram has a lot of experience with actual deployments.  Pretend that
>>he knows what he is doing.
>>    
>>
>
>You can't seriously mean that arbitrary allocation of ports in the
>IANA reserved range by individual software manufacturers is a good
>thing?  Further, someone mentioned a post by Bram in which he
>recognized that this particular part of the protocol documentation
>was unfortunate. It's a non-issue AFAICS, since all clients always
>tell the tracker which port they're using.
>
>  
>
Actually I do think it is a good thing that software developers allocate 
ports in the absence of IANA's blessing, but that is a different and 
very philosophical discussion. 

>As for firewalls, that's another issue, I think the best solution
>would be for Bram to get a port allocated by IANA and then all BT
>software could use that as the default. Until then, nothing we do
>in libbt will be of much help for firewall operators..
>
>Plus; users should be able to pick the port if they want.
>
>  
>
On this we agree; without a doubt users should be able to pick their own 
ports.