за 1 час утянул 22 мб
отдал примерно столько же
Да вот ссылка на sourceforge Bittorrent (http://sourceforge.net/projects/bittorrent/
там и офф клиент а здесь (http://ei.kefro.st/projects/btclient/ есть мод клиента
и почему все молчат
ЛЮДИ ВЫ ГДЕ
|
Printable Version of Topic
Click here to view this topic in its original format |
| Forums > Флейм > Bittorrent, ещё одна П2П |
| Posted by: Roma_il on 20-07-2003, 17:47 |
|
Нашёл вот здесь топик на форуме (http://glanz.ru/forum/index.php?act=ST&f=4&t=969 у Glanzа Ссылка на саму прогу клац (http://bitconjurer.org/BitTorrent/download.html просьба не бить за ссылку на другой форум копировать всё лень а описанно толково Мож шо и получится никто не хочет опробовать на себе ? |
| Posted by: Roma_il on 20-07-2003, 19:54 |
|
Прога работает за 1 час утянул 22 мб отдал примерно столько же Да вот ссылка на sourceforge Bittorrent (http://sourceforge.net/projects/bittorrent/ там и офф клиент а здесь (http://ei.kefro.st/projects/btclient/ есть мод клиента и почему все молчат ЛЮДИ ВЫ ГДЕ
|
| Posted by: Billy Bonce on 20-07-2003, 20:04 |
Здесь мы, здесь  А что у Bittorrent есть в плане защиты от тещи(тм)? |
| Posted by: Roma_il on 20-07-2003, 20:09 |
|
Выдрал из FAQа How do I know the download isn't corrupted? BitTorrent does cryptographic hashing (SHA1) of all data. When you see "Download Succeeded" you can be sure that BitTorrent has already verified the integrity of the data. The integrity and authenticity of a BitTorrent download is as good as the original request to the tracker. Checking the MD5 of a file downloaded via BitTorrent is redundant. вот только не понял ничего кто английский учил ПЕРЕВЕДИТЕ ПЛЗ |
| Posted by: Billy Bonce on 20-07-2003, 20:15 |
| В двух словах - Bittorrent поддерживает хэширование,т.е. каждый чанк проверяется на отсутствие ошибок (как и ослик,кстати) |
| Posted by: Roma_il on 20-07-2003, 20:26 |
|
Вот описание протокола + линк на оригинал__________ (http://bitconjurer.org/BitTorrent/protocol.html BitTorrent is a protocol for distributing files. It identifies content by url and is designed to integrate seamlessly with the web. Its advantage over plain http is that when multiple downloads of the same file happen concurrently, the downloaders upload to each other, making it possible for the file source to support very large numbers of downloaders with only a modest increase in its load. The life cycle of a BitTorrent file distribution. A BitTorrent file distribution consists of these entities - An ordinary web server A static 'metainfo' file A BitTorrent tracker An 'origin' downloader The end user web browsers The end user downloaders There are ideally many end users for a single file. To start serving, a host goes through the following steps - Start running a tracker (or, more likely, have one running already). Start running an ordinary web server, such as apache, or have one already. Associate the extension .torrent with mimetype application/x-bittorrent on their web server (or have done so already). Generate a metainfo file using the complete file to be served and the url of the tracker. Put the metainfo file on the web server. Link to the metainfo file from some other web page. Start a downloader which already has the complete file (the 'origin'). To start downloading, a user does the following - Run a BitTorrent installer (or have done so already). Web surf. Click on a link to a .torrent file. Select where to save the file locally, or select a partial download to resume. Wait for download to complete. Tell downloader to exit (it keeps uploading until this happens). The connectivity is as follows - The web site is serving up static files as normal, but kicking off the BitTorrent helper app on the clients. The tracker is receiving information from all downloaders and giving them random lists of peers. This is done over http or https. Downloaders are periodically checking in with the tracker to keep it informed of their progress, and are uploading to and downloading from each other via direct connections. These connections use the BitTorrent peer protocol, which operates over TCP. The origin is uploading but not downloading at all, since it has the entire file. The origin is necessary to get the entire file into the network. Often for popular downloads the origin can be taken down after a while since several downloads may have completed and been left running indefinitely. Metainfo file and tracker responses are both sent in a simple, efficient, and extensible format called bencoding (pronounced 'bee encoding'). Bencoded messages are nested dictionaries and lists, which can contain strings and integers. Extensibility is supported by ignoring unexpected dictionary keys, so additional optional ones can be added later. Bencoding is done as follows - Strings are length-prefixed base ten followed by a colon and the string. For example '4:spam' corresponds to 'spam'. Integers are represented by an 'i' followed by the number in base 10 followed by an 'e'. For example 'i3e' corresponds to 3 and 'i-3e' corresponds to -3. Integers have no size limitation. 'i-0e' is invalid. All encodings with a leading zero, such as 'i03e', are invalid, other than 'i0e', which of course corresponds to 0. Lists are encoded as an 'l' followed by their elements (also bencoded) followed by an 'e'. For example 'l4:spam4:eggse' corresponds to ['spam', 'eggs']. Dictionaries are encoded as a 'd' followed by a list of alternating keys and their corresponding values followed by an 'e'. For example, 'd3:cow3:moo4:spam4:eggse' corresponds to {'cow': 'moo', 'spam': 'eggs'} and 'd4:spaml1:a1:bee' corresponds to {'spam': ['a', 'b']} . Keys must be strings and appear in sorted order (sorted as raw strings, not alphanumerics). Metainfo files are bencoded dictionaries with the following keys - 'announce' The url of the tracker. 'info' This maps to a dictionary, with keys described below. The 'name' key maps to a string which is the suggested name to save the file (or directory) as. It is purely advisory. 'piece length' maps to the number of bytes in each piece the file is split into. For the purposes of transfer, files are split into fixed-size pieces which are all the same length except for possibly the last one which may be truncated. Piece length is almost always a power of two, most commonly 220. 'pieces' maps to a string whose length is a multiple of 20. It is to be subdivided into strings of length 20, each of which is the sha1 hash of the piece at the corresponding index. There is also a key 'length' or a key 'files', but not both or neither. If 'length' is present then the download represents a single file, otherwise it represents a set of files which go in a directory structure. In the single file case, 'length' maps to the length of the file in bytes. For the purposes of the other keys, the multi-file case is treated as only having a single file by concatenating the files in the order they appear in the files list. The files list is the value 'files' maps to, and is a list of dictionaries containing the following keys - 'length' The length of the file, in bytes. 'path' A list of strings corresponding to subdirectory names, the last of which is the actual file name (a zero length list is an error case). In the single file case, the 'name' key is the name of a file, in the muliple file case, it's the name of a directory. Tracker queries are two way. The tracker receives information via GET parameters and returns a bencoded message. Note that although the current tracker implementation has its own web server, the tracker could run very nicely as, for example, an apache module. Tracker GET requests have the following keys - 'info_hash' The 20 byte sha1 hash of the bencoded form of the 'info' value from the metainfo file. Note that this is a substring of the metainfo file. This value will almost certainly have to be escaped. 'peer_id' A string of length 20 which this downloader uses as its id. Each downloader generates its own id at random at the start of a new download. This value will also almost certainly have to be escaped. 'ip' An optional parameter giving the ip (or dns name) which this peer is at. Generally used for the origin if it's on the same machine as the tracker. 'port' The port number this peer is listening on. Common behavior is for a downloader to try to listen on port 6881 and if that port is taken try 6882, then 6883, etc. and give up after 6889. 'uploaded' The total amount uploaded so far, encoded in base ten ascii. 'downloaded' The total amount downloaded so far, encoded in base ten ascii. 'left' The number of bytes this peer still has to download, encoded in base ten ascii. Note that this can't be computed from downloaded and the file length since it might be a resume, and there's a chance that some of the downloaded data failed an integrity check and had to be re-downloaded. 'event' This is an optional key which maps to 'started', 'completed', or 'stopped' (or '', which is the same as not being present). If not present, this is one of the announcements done at regular intervals. An announcement using 'started' is sent when a download first begins, and one using 'completed' is sent when the download is complete. No 'completed' is sent if the file was complete when started. Downloaders send an announcement using 'stopped' when they cease downloading. Tracker responses are bencoded dictionaries. If a tracker response has a key 'failure reason', then that maps to a human readable string which explains why the query failed, and no other keys are required. Otherwise, it must have two keys - 'interval', which maps to the number of seconds the downloader should wait between regular rerequests, and 'peers'. 'peers' maps to a list of dictionaries corresponding to peers, each of which contains the keys 'peer id', 'ip', and 'port', which map to the peer's self-selected id, ip address or dns name as a string, and port number, respectively. Note that downloaders may rerequest on nonscheduled times if an event happens or they need more peers. If you want to make any extensions to metainfo files or tracker queries, please coordinate with Bram Cohen to make sure that all extensions are done compatibly. BitTorrent's peer protocol operates over TCP. It performs efficiently without setting any socket options. Peer connections are symmetrical. Messages sent in both directions look the same, and data can flow in either direction. The peer protocol refers to pieces of the file by index as described in the metainfo file, starting at zero. When a peer finishes downloading a piece and checks that the hash matches, it announces that it has that piece to all of its peers. Connections contain two bits of state on either end - choked or not, and interested or not. Choking is a notification that no data will be sent until unchoking happens. The reasoning and common techniques behind choking are explained later in this document. Data transfer takes place whenever one side is interested and the other side is not choking. Interest state must be kept up to date at all times - whenever a downloader doesn't have something they currently would ask a peer for in unchoked, they must express lack of interest, despite being choked. Implementing this properly is tricky, but makes it possible for downloaders to know which peers will start downloading immediately if unchoked. Connections start out choked and not interested. When data is being transferred, downloaders should keep several piece requests queued up at once in order to get good TCP performance (this is called 'pipelining'.) On the other side, requests which can't be written out to the TCP buffer immediately should be queued up in memory rather than kept in an application-level network buffer, so they can all be thrown out when a choke happens. The peer wire protocol consists of a handshake followed by a never-ending stream of length-prefixed messages. The handshake starts with character ninteen followed by the string 'BitTorrent protocol'. The leading character is a length prefix, put there in the hope that other new protocols may do the same and thus be trivially distinguishable from each other. All later integers sent in the protocol are encoded as four bytes big-endian. After the fixed headers come eight reserved bytes, which are all zero in all current implementations. If you wish to extend the protocol using these bytes, please coordinate with Bram Cohen to make sure all extensions are done compatibly. 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. After the download hash comes the 20-byte peer id which is reported in tracker requests and contained in peer lists in tracker responses. If the receiving side's peer id doesn't match the one the initiating side expects, it severs the connection. That's it for handshaking, next comes an alternating stream of length prefixes and messages. Messages of length zero are keepalives, and ignored. Keepalives are generally sent once every two minutes, but note that timeouts can be done much more quickly when data is expected. All non-keepalive messages start with a single byte which gives their type. The possible values are - 0 - choke 1 - unchoke 2 - interested 3 - not interested 4 - have 5 - bitfield 6 - request 7 - piece 8 - cancel Choke, unchoke, interested, and not interested have no payload. Bitfield is only ever sent as the first message. Its payload is a bitfield with each index that downloader has sent set to one and the rest set to zero. Downloaders which don't have anything yet may skip the bitfield message. The first byte of the bitfield corresponds to indices 0-7 from high bit to low bit, respectively. The next one 8-15, etc. Spare bits at the end are set to zero. The have message's payload is a single number, the index which that downloader just completed and checked the hash of. Request messages contain an index, begin, and length. The last two are byte offsets. Length is generally a power of two unless it gets truncated by the end of the file. All current implementations use 215, and close connections which request an amount greater than 217. Cancel messages have the same payload as request messages. They are generally only sent towards the end of a download, during what's called 'endgame mode'. When a download is almost complete, there's a tendency for the last few pieces to all be downloaded off a single hosed modem line, taking a very long time. To make sure the last few pieces come in quickly, once requests for all pieces a given downloader doesn't have yet are currently pending, it sends requests for everything to everyone it's downloading from. To keep this from becoming horribly inefficient, it sends cancels to everyone else every time a piece arrives. Piece messages contain an index, begin, and piece. Note that they are correlated with request messages implicitly. It's possible for an unexpected piece to arrive if choke and unchoke messages are sent in quick succession and/or transfer is going very slowly. Downloaders generally download pieces in random order, which does a reasonably good job of keeping them from having a strict subset or superset of the pieces of any of their peers. Choking is done for several reasons. TCP congestion control behaves very poorly when sending over many connections at once. Also, choking lets each peer use a tit-for-tat-ish algorithm to ensure that they get a consistent download rate. The choking algorithm described below is the currently deployed one. It is very important that all new algorithms work well both in a network consisting entirely of themselves and in a network consisting mostly of this one. There are several criteria a good choking algorithm should meet. It should cap the number of simultaneous uploads for good TCP performance. It should avoid choking and unchoking quickly, known as fibrillation. It should reciprocate to peers who let it download. Finally, it should try out unused connections once in a while to find out if they might be better than the currently used ones, known as optimistic unchoking. The currently deployed choking algorithm avoids fibrillation by only changing who's choked once every ten seconds. It does reciprocation and number of uploads capping by unchoking the four peers which it has the best download rates from and are interested. Peers which have a better upload rate but aren't interested get unchoked and if they become interested the worst uploader gets choked. If a downloader has a complete file, it uses its upload rate rather than its download rate to decide who to unchoke. For optimistic unchoking, at any one time there is a single peer which is unchoked regardless of it's upload rate (if interested, it counts as one of the four allowed downloaders.) Which peer is optimistically unchoked rotates every 30 seconds. To give them a decent chance of getting a complete piece to upload, new connections are three times as likely to start as the current optimistic unchoke as anywhere else in the rotation. |
| Posted by: Roma_il on 20-07-2003, 20:28 |
|
Один плюс есть у програмки точно отдавать начинаепрактически с первых 100кб |
| Posted by: Roma_il on 21-07-2003, 11:12 |
|
Во уже скачал фильм на всё провсё ушло времени ~11 часов за это время отдано 320 мб скачано 700мб (кабельный инет 64/256) средняя скорость ниже 15кб опускалась редко я доволен кстати при создании хеш файла можно выставить размер чунков от 128кб до 2мб |
| Posted by: mda on 23-07-2003, 07:23 |
| roma a nemnojko podrobnie kak nastroil? ya chto to v nei zaputalsya |
| Posted by: nesher on 23-07-2003, 08:53 |
| Что значит как настроил. там настроек то и нету |
| Posted by: Roma_il on 23-07-2003, 09:29 |
|
О кстати эту прогу можно пользовать для подготовки релизов скажем нужно зарелизить что то а у того кто хочет релизить ап савсем никакой - раздавать по фтп 5 раз неинтересно а так довольно просто и про раздачу никто не пронюхает пока торрент файл передаётся скажем почтой - каких то 60кб всего |
| Posted by: Roma_il on 23-07-2003, 09:36 | ||
Там и в самом деле практически нет настроек к серверу нужному оно само коннектится - он вписан в торрент всё что от тебя требуется так это указать куда "складывать" файл и если у тебя слабенький ДСЛ с апом ниже 10кб/с ставить настройки скорости для диал ап/исдн вот собственно и всё Да настройки скорости я видел только в этом (http://ei.kefro.st/projects/btclient/ моде клиента |
| Posted by: LF_ on 23-07-2003, 22:55 |
|
There is good news and bad news about BitTorrent: The good news is that the RIAA has admitted it is not currently targeting the BitTorrent network for subpoena action. The bad news comes from the network designer, Bram Cohen, who told ZDNet that BitTorrent is a very poor choice for maintaining user privacy: "Distributing stuff that is clearly illegal with BitTorrent is a really dumb idea," said Cohen, who advocates using the software to distribute large uncopyrighted files such as open-source programs. "BitTorrent doesn't have any anonymity features. There are things about it that make it very incompatible with anonymity." -- ZDNet Because all users who transfer a file share their IP address with every other user downloading it, it becomes very simple to track users from a central location, unlike Kazaa's supernode system which can only reveal the identity of users connected to that supernode and others nearby. |
| Posted by: Roma_il on 24-07-2003, 00:40 |
Короче всё ясно я так думаю лучше это не юзать
|
| Posted by: Flashget on 24-07-2003, 01:59 |
Хмм, насколько я понимаю не так уж страшен чёрт как Roma_il его малюет  Просто эта страничка предоставляет место для хранения torrent файлов, и авторы предупреждают что при появлении иллегальных файлов они накатают телегу Большому Брату ... Решение проблемы : Выкладывать торренты не на этом дурацком сайте а на Нетлабе  или бесплатном webspace  Кстати в продолжении закрытого топика о тестовом релизе через битторрент: У меня тоже была такая идея, посмотреть что у меня интересненького ещё есть и попробовать зарелизить, уж больно скорости заманчивые... Кстати и с безопасностью дела обстоят не так уж и плохо, надо просто торрентфайлы в архивах с паролем вакладывать и ссылку в нетлабе на форуме давать, думаю до русских форумов RIAA доберётся ещё нескоро С помощью этого способа мы отсекём всех левых людей, так как поиска в битторенте нет по определению..., ну а провайдеры пока битторентовские протоколы не отслеживают насколько я знаю, потому как он не настолько популярен как ослик 
|
| Posted by: Roma_il on 24-07-2003, 02:13 | ||
Ну в общем то есть одно НО программы которая всю эту лабуду сервит (трекер) я нигде не нашёл А если ты не заметил сайты на которых выкладывают торренты держат так же и сервера так что думай сам Вот если заиметь свой трекер улудшенной конфигурации (ssl там всякие) клиента который не покажет ИПов ни в каком виде(зашифровать 128бит) тогда ешё можно говорить об этой проге а так ну его в пень |
| Posted by: ikki on 26-07-2003, 18:21 |
|
http://suprnova.outlive.net/list_news.html (http://suprnova.outlive.net/list_news.html testiruem 48 Hrs. (1982).rus.divx. |
| Posted by: Roma_il on 02-08-2003, 21:40 |
|
Насчет треккера был неправ, сегодня нашёл и скачал вот только бы разобраться с настройками  Весь фокус в том что для того чтобы трекер сервил файл X нужно аплоадить торрент этого файла X на треккер просто создать торрент недостаточно Если б были желающие можно было бы поэксперементировать в отличии от Waste эта прога работает но увы для тех кто боится получить письмо ничего кроме скорости скачивания не даёт те тот же ослик но без чата, IRC и без поиска файлов по сети хотя если распостранять таким образом скажем ТВ рипы, всякие клипы то думаю не у каких тёщь претензий не будет я думаю вы понимаете о чем я говорю |
| Posted by: Wolf847 on 17-08-2003, 20:42 |
|
Штука полезная для раздачи релизов в пределах клубов, форумов и т. д. То есть, ограниченному кругу людей, ибо скачать может только тот, у кого есть .torrent файл, в нем же идет привязка к конкретному трекеру. Если поставить свой трекер, и доступ к .torrent файлу давать только мемберам, то кроме них никто ничего не увидит и скачать не сможет. И никакие RIAA и иже с ними просто так увидеть кто и что качает не сможет, если говорить про русско-язычные сайты. А по поводу IP, так при некоторых знаниях и наличии исходников мула можно рядом в хэшем выводить и IP. Так что разницы никакой между ними в этом плане нет. Директ коннет никто не отменял. Штуку попробовали, впечатления весьма положительные. Где пробовали, говорить не буду, сочтут за рекламу Реально за время одной отдачи всего файла даже раздающим с низким аплодом его могут скачать сотни желающих. В режиме super seed все части файла могут быть распределены между разными качающими всего при отдаче ~105% объема файла, как написано в описании режима. Ну и размер части можно задать самому от 32K до 2MB, что весьма радует. Такие части проще расходятся на узких аплодах чем части по 9 MB. Кстати, в режиме super seed нельзя даже сказать, кто начал раздачу, ибо никто не видит полного источника, который отдает только новые или редкие части. Положительный момент. Скачка идет сразу после начала, зашедшие позже уже умудрялись скачать весь фильм за 4-6 часов. За сутки - двое фильм скачали все пожелавшие 25 человек, при этом два seed-а в обычном режиме отдали в сумме ~7 GB. Вообще, если антипиратские организации серьезно займутся за p2p, то именно за такими системами будущее. Как минимум, для русско-язычных сайтов это будет выходом хоть на какое-то время. |
| Posted by: Tehnari on 16-09-2003, 09:40 |
Да будущее есть у проги, особенно если учесть что идет подержка не только windows-a  
|
| Posted by: lbarsov on 16-09-2003, 19:13 |
| Wolf847, как эта штука по сравнению с ослом качает? |
| Posted by: Steyr on 16-09-2003, 21:11 |
Хы-ы-ы... я эту штуку пробовал, и запостить сюда хотел, но нетлаб тада лежал  а потом я забыл совсем про него  Там клиенты есть более нормальные, не такие как дубовый оф.клиент. Вот внатурь интересно было бы протестить его накинувшись толпой.
|
| Posted by: Lin on 17-09-2003, 01:18 |
|
Всем Привет! Bittorent сеть классная,качается все быстро и без каких-либо ожиданий и очередей,но в ней есть несколько проблем,Первое: Если падает трекер (сервер который держит torrent файл),то этот файл уже с другого сервера не скачать,если у трекера меняется адрес,то значит надо тому кто выложил torrent файл делать изменения адреса сервера в torrent файле и заново ресидить файл (reseed) Второе : Если на файл нет сидеров (seeders- люди с полными источниками) то опять же файл будет не докачать пока не появится полный источник,конечно людям с толстыми каналами это не большая проблема,потому как полный файл будет у них уже лежать через пару-тройку часов после появления его на сервере,но мне лично на модеме пришлось неделю ждать пока докачал ISO образ ;-( И все из-за того что трекер на Suprnova упал,и пока подняли трекер,потом пока народ с файлом опять появился,прошло немало времени.. Потом опять же в Bittorent нет поиска и многие вещи которые хотелось бы скачать,не найти ;-( Собстно мое резюме : Если будет трекер ,у которого есть постоянный адрес и он будет работать 24/7 без проблем,то сетка будет стоящая и качать будет одно удовольствие. |
| Posted by: Jameson on 30-09-2003, 06:15 |
| Только сырой он еще - отдельной проги, при запуске которой старотовала бы загрузка -нету.. Встраивается в IE и если по-умолчанию стоит Опера -то не оживает и не качает.. при сбое выдает окошко, и пока не закроешь -не продолжает.. Ждем мод Мула для работы с torrents. |
| Posted by: inzerus on 30-09-2003, 13:55 |
| Попробовал и мне понравилось: я скачал фильм за 24 часа - это очень неплохо при моем слабом канале. Для сравнения, у меня в муле есть фильмы, которые я качаю уже несколько месяцев и пока конца-края не видно. Минус: нужно знать места, где эти фильмы/файлы выкладываются, а их пока не очень много. Меня интересуют неголливудские фильмы и музыка, а таких пока немного. |
| Posted by: yurinb on 30-09-2003, 21:02 | ||
я битторенты шареазой качаю http://www.shareaza.com/ (http://www.shareaza.com/, добавил его в закачку и больше руками ничего делать не надо. |
| Posted by: lukamor on 04-10-2003, 17:01 | ||
Если кому интересно,то уже есть русские фильмы (http://members.lycos.co.uk/cdivx/index.php и в Битторенте. Извиняюсь если нарушил какие правила...
|
| Posted by: AmnoN on 14-10-2003, 13:04 |
| Вот здесь (http://suprnova.web.siol.com/ ещё не плохой сайт с ссылками Bittorrentыми. |
| Posted by: Jameson on 15-10-2003, 03:07 |
|
У меня шареаза не качает торренты. зато нашел вот это - http://cesnet.dl.sourceforge.net/sourcefor...p-0.5.4-bin.exe (http://cesnet.dl.sourceforge.net/sourceforge/btplusplus/BTpp-0.5.4-bin.exe хороший такой клиент, стартует закачку сам при запуске проги, место резервирует заранее, правда, передрался со spider guard - создал огромные файлы, spider стал их проверять, а bittorrent++ стал считать хеш..  и тормозаа..
|
| Posted by: Advanced_User on 02-11-2003, 16:16 |
|
Народ, я пару дней назад открыл для себя BitTorrent. Я просто ПОРАЖЁН - качается сразу и на большой скорости
|
| Posted by: yurinb on 04-11-2003, 21:35 |
|
В есть посиковит типа jigle или filedonkey для поиска торентов? А то задолбаешься пока что нибудь редкое найдешь, а скорее всего не найдешь
|
| Posted by: Flashget on 05-11-2003, 18:05 |
| Нету такого, сам принцип сети не позволяет делать поиска, единственная возможность: каждый день просматривать сайты с торрентами и надеятся что кто то зарелизит искомое, ну или в форуме попросить... |
| Posted by: Arbakesh on 07-11-2003, 03:07 | ||
Есть такая программка,называется Torrent Search. Скачать её можно здесь: http://torrentsearch.bounceme.net/ (http://torrentsearch.bounceme.net/ Или в Ослике (ed2k://|file|TorrentSearch_v3_2_1_final.zip|1017102|FC442AA1A03B2539B26F79364B3B4E4F|/ |
| Posted by: JoG on 14-11-2003, 19:11 |
| Поисковик по торрент-сайтам http://isohunt.com/ (http://isohunt.com/ Не фонтан. |
| Posted by: Power User on 15-11-2003, 03:37 |
|
счас мы их проверим... счас мы их сравним... |
| Posted by: Power User on 15-11-2003, 08:50 |
|
а чего !? работает ! за пять часов с копейками 1.2 гига усосало.... |
| Posted by: PSI on 17-11-2003, 20:47 |
| А этот Bittorrent вы паралелльно с осликом используете или вместе они не пашут? |
| Posted by: Power User on 17-11-2003, 22:11 |
|
паралельно - они никак не связаны... |
| Posted by: izanoza on 17-11-2003, 22:16 |
|
.... Ослов и Торрентов можно пасти и вместе, на одной лужайке, если она конечно широкая. Если же лужайки бедны растительностью, то в условиях жестокой конкуренции, когда корма становится всё меньше и меньше, ослики очень быстро худеют и становятся рахитиками. Парнокопытные Торренты также страдают от нехватки пищи. Обычно, корма перестаёт хватать и другим животным, таким как загадочная птица ФиТиПе, кролик Эксплорер (подвид зайца Мозайца), и муха Моззилла... В такой неурожайный сезон последнии дохнут прямо на взлёте или становятся медленными и заторможенными, практически не принося ничего в виде мяса/пуха/шерcти. Так что, животноводам практически ничего не достаётся.... Сезон неурожая... Животноводы звереют и становятся оходниками, безжалостно отстреливая один из видов, обычно менее ценный в данное время. Выжившая живность, почуяв запах крови убитого врага, сразу же начинает веселится и жиреть просто на глазах... (программа "В мире животновода", ноябрь, 2003 г. ) |
| Posted by: Silkmann on 18-11-2003, 14:28 |
|
...хуже всего, когда на одной лужайке пасутся питомцы нескольких владельцев. Дистрофические преобразования подопечных животных и насекомых вызывают у людей агрессивность и нервозность. Как следствие животноводы всячески пытаются скрыть факт кормления и идут на всяческие ухищрения. Если оказывается, что оба животновода являются сертифицированными пастухами, между ними может разразится конфликт с использованием изощрённых методов уничтожения "чужих" осликов (отравление, ограждение, приводящее к голоду, отстрел и даже загадочный ритуал "Перекрытие Портов"). Но самое ужастное, когда владельцами поляны являются далеко не ословоды. А настоящие хозяева начинают понимать, что безобидные (на первый взгляд) животные приносят газону намного больше вреда, чем секретарша Ася, приминающая его своими тонкими ножками, и столяр Иван, таскающий через него свои ящики с видеокассетами.... (программа "Люди и Звери: вечное противостояние", тот же ноябрь) |
| Posted by: ikki on 13-12-2003, 01:07 |
|
Azureus.rus Link (http://belnet.dl.sourceforge.net/sourceforge/azureus/Azureus_2.0.3.2_setup.exe http://azureus.sourceforge.net/ (http://azureus.sourceforge.net/ 
|
| Posted by: Forrest on 13-12-2003, 04:09 |
| и что ж это такое? реклама нового клиента? в таком случае лучше топик создать .... |
| Posted by: Pirater on 15-12-2003, 01:59 |
|
очень приятно читать хорошие отзывы о горячо любимом БТ.
|
| Posted by: eFox on 19-12-2003, 02:49 |
| Ещё один адрес для ВТ поиска: <<--click-->> (http://novasearch.net/ |
| Posted by: X-factor on 19-12-2003, 09:06 |
|
А вот ещё сайт (http://www.upashi.com/ с русскими ссылками для Bittorrent . ИМХО был бы у Bittorrent`а поиск то ослик мог бы только нервно курить в уголке.
|
| Posted by: Roma_il on 19-12-2003, 17:12 |
|
Ну вот у Азуреуса есть свой собственный встроенный треккер это есть гут а зачем поиск нужен ведь почти всё что скачиваем берем ссылки с форумов вон матриц целый десяток найти в муле можно а толку ? Почти все они фальшивки а проги всякие можно на SuprNova.org (http://www.suprnova.org/ найти сколько хочеш и игрушек там валом ИМХО поиск это лишнее для этой сети Всё что нужно можно найти на самом треккере |
| Posted by: X-factor on 19-12-2003, 20:14 | ||
Roma_il Иногда хочется скачать альбомчик какой нибудь определённый, ну или например архив так чтоб и кряк и варез в одном флконе.  В этом плане мулу равных нет. А на супернове там даже то что у них лежит не имеет описаний я уже не говорю о поиске по всей сети.Так что, (опять таки ИМХО) рано ещё переходить на Bittorrent , можно иногда включить скачать что то определённое, ну или например , как уже предлогали подготовить релиз для раздачи но не более. |
| Posted by: ikki on 30-01-2004, 05:35 |
|
Radio (2003).rus.torrent http://us.imdb.com/title/tt0316465/ (http://us.imdb.com/title/tt0316465/ Формат: DivX Качество: Видео: 608x320 Аудио: 48000 Hz / XviD Перевод: Проф.закадровый Размер: 693 MB TORRENT FAIL : http://195.250.168.214 (http://195.250.168.214 |
| Posted by: VICsTORm on 30-01-2004, 16:04 | ||
Не скажи... Например я качаю редкую музыку (ну не жду релизов, а вот захотелось вдруг такую то группу послушать..), а искать ее по всем форумам это такие проблемы... Проще поиск сделать, и усё. |
| Posted by: ikki on 02-02-2004, 13:12 | ||
http://bittorrent.rusboard.com/ (http://bittorrent.rusboard.com/ |
| Posted by: VICsTORm on 02-02-2004, 16:34 |
|
А я вот не понимаю, чем биттурнет или ослосеть лучше той же казы? Только тем что ссылки не перехватывает из браузера? У нас в латвии вообще очень популярна система ДЦ++ файйлы качаются на максимальной скорости. Только плохо что с одного источника одновременно. Но если связь между клиентами в порядке, то забивает весь канал. А мулом я пользуюсь, а не казой только изза того что почемуто русского софта и фильмов там нет... Хотя скорость... В общем я вообще в недоумении почему россияне сели именно на осла. |
| Posted by: deaddimitri on 12-02-2004, 17:54 |
|
DirectConnect недалеко ушел от того же напстера или ftp. Если надо качать большие файлы, большую роль играет умение проги разбивать файл на части. В DC этого, увы, нет. А Торрент мне очень нравится. Если файл качают много народу, скорость всегда отличная. И аплоад не утекает "в никуда". Если он большой, то и качать будешь быстро.
|