[bittorrent] bittorrent] One connection for download and upload?

Alan McGovern alan.mcgovern at gmail.com
Fri Nov 3 11:21:43 EST 2006


Hi,

> My question is ,at certain moment , peer B realizes peer A also has data I
> need. Will peer B initiate another connection to peer A or he will try to
> use the existing connection between peer A and B?
>
Then peer B will immediately send an Interested message to peer A across the
existing connection. TCP connections are 2 way communication channels. Data
can (and does) simultaenously flow to and from a peer over the same
connection. While it would be possible to build a client that uses a
different socket for sending and a different one for receiving you'll have
problems in that all other BitTorrent clients will send data down the wrong
socket to you.

On 11/3/06, Yao-Chin Wu <yaochinwu at yahoo.com> wrote:
>
> Thanks Alan and Joris!
>
>     Although you both answer my question - most clients will probably
> refuse a second connection from a peer it is already connected to, I think
> you probably miss my idea a little bit. When there is a peer A wants to
> download data from peer B. They exchange the handshake messages and peer B
> responses a bitfield message through one conneciton. I think we all agree
> that things should go in this way. My question is ,at certain moment , peer
> B realizes peer A also has data I need. Will peer B initiate another
> connection to peer A or he will try to use the existing connection between
> peer A and B? Is it ture that no Bittorrent client was implemented in this
> way? Thank you for your help! :) Sorry! my last message probably confussed
> you.
>
> Yao-Chin
>
> *Alan McGovern <alan.mcgovern at gmail.com>* wrote:
>
> Hi,
>
> Besides, in typical case, a peer may not always need to send and receive
> data from the same peer.
> Firstly, that's wrong ;) The very first message that *must* be sent to
> each peer that is trying to connect to each other is the handshake message.
> Then the bitfield message must be next, which also must be sent between both
> peers. If you want to request a piece off the other client, you must send
> them a RequestMessage.
>
> It becomes extremely messy when you are trying to keep track of which
> socket is for incoming data and which is for outgoing data. Finally, most
> clients will not accept two connections from the same peer, so you'd find
> that you'd never receive data from them.
>
> It's not so much the bittorrent standard that says connections are
> symmetrical, it's more the TCP standard was designed with this in mind as
> it's more efficient than havingtwo maintain 2 sockets just to talk to one
> peer.
>
>
>
> On 11/3/06, Joris Guisson <joris.guisson at gmail.com> wrote:
> >
> > There is no client which uses 2 connections, you do not have a choice in
> > this matter, you use one connection per peer. Most clients will probably
> > refuse a second connection from a peer it is already connected to.
> >
> > Joris,
> >
> > On 11/3/06, Yao-Chin Wu < yaochinwu at yahoo.com> wrote:
> > >
> > > Thank you for your prompt response.
> > >
> > > I have this idea mainly because it is easier to implement. The thread
> > > handles its own inbound or outbound connection can focus only on its own
> > > job.
> >
> > Besides, in typical case, a peer may not always need to send and receive
> > > data from the same peer. But, it seems like it is not a good idea at all. If
> > > other members can also provide your opinion, that will also be appreciated.
> > >
> >
> >
> > BTW, Mike mentioned that one connection is the standard in this
> > > situation. And there is a short paragraphe in Bittorrent protocal, which
> > > says,"Peer connections are symmetrical. Messages sent in both directions
> > > look the same, and data can flow in either direction." Does your point come
> > > from here? If it is the standard, there must be no Bittorrent client
> > > designed to use separated connections because it could even fail to work
> > > with other existing implmentation: one peer cannot handle download and
> > > upload in one connectoin while its uploader assumes it could, and send a
> > > request message through this connection and would never get response. Thank
> > > you.
> >
> >
> >
> >
> >  *Alan McGovern <alan.mcgovern at gmail.com>* wrote:
> > >
> > > Hi,
> > >
> > > There's no point in not using the same connection to both send and
> > > receive data. No program that i know of would use a seperate socket to send
> > > data and receive data from the the same host, it's inefficient and awkward.
> > >
> > > Thanks,
> > > Alan.
> > >
> > > (forgot to hit "reply to all" the first time, sorry)
> > >
> > >
> > > On 11/2/06, Michael Parker <mgp at ucla.edu> wrote:
> > > >
> > > >
> > > > On Nov 2, 2006, at 8:22 AM, Yao-Chin Wu wrote:
> > > > > Dear all,
> > > > >
> > > > >     I am a college student and doing a project related to P2P
> > > > > structure. Bittorrent is a excellent resource for us, and we are
> > > > > trying to understand its code as much as possible.
> > > > >
> > > > >     Accroding to the Bittorrent client implemented by Bram Cohen,
> > > > > it looks like using only one connection when peer A is downloading
> > > > > a piece from peer B and peer B also wants to download a piece from
> > > >
> > > > > peer A ( one connection for downloading and uploading also). Is
> > > > > that correct? Is there other implementatioins using seperated
> > > > > connections for this situation? Which one may be better? Thank you
> > > >
> > > > > for your help!
> > > > >
> > > >
> > > > Yes, the standard is that there is only one connection between them.
> > > > I don't think there's much point to separated connections for
> > > > uploading and downloading -- by using a single connection you can
> > > > cut
> > > > the overhead from the TCP headers in half. Also, if two different
> > > > connections were used, that gives me the impression that each side
> > > > is
> > > > responsible for creating one of the connections (although not
> > > > necessarily). But with the prevalence of NATs and firewalls today,
> > > > you'd be running a greater risk of one side not being able to
> > > > connect
> > > > at all, and hence one side not being able to download or upload at
> > > > all.
> > > >
> > > > - Mike
> > > >
> > > >
> > > > _______________________________________________
> > > > 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
> > >
> > >
> > > ------------------------------
> > > Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates.<http://us.rd.yahoo.com/mail_us/taglines/postman8/*http://us.rd.yahoo.com/evt=39663/*http://voice.yahoo.com>
> > >
> > > _______________________________________________
> > > 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
> >
> >
> >
>
> ------------------------------
> Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates.<http://us.rd.yahoo.com/mail_us/taglines/postman8/*http://us.rd.yahoo.com/evt=39663/*http://voice.yahoo.com>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ibiblio.org/pipermail/bittorrent/attachments/20061103/3bae644c/attachment.html 


More information about the BitTorrent mailing list