Page 3 of 3 FirstFirst 123
Results 21 to 22 of 22

Thread: multiplayer (and LNet)

  1. #21
    Quote Originally Posted by phibermon View Post
    You don't have to adhere to the bit-torrent protocol, you can do multi-part sharing of your own accord, split into arbirary parts, get the hash of each part (MD5 etc) and use it to confirm each part as it's transferred. A simple list of confirmed aquired parts (or fully downloaded etc) and you're onto a winner. I think bit-torrent does some funky hashing that allows it to CRC check individial parts from just having the entire file/torrent hash (some funky maths going on there) but you really don't need that. just store a file similar to a .torrent that contains a list of all the parts, their start-end offsets and their CRCs. You can flag the bits you've got in the hashing file so you can resume downloads. A process that calculates the CRC of the parts from the file you have can be used to determine what's good in the instance of a program crash / unclean shutdown.
    Seems logic, but why to invent the wheel if it already exists? One thing I want to use from bittorrent protocol is a new feature that allows to stream data the way you want. Actually it's focused to allow video stream over a p2p network, no one said it's the only use it. Also want to build a chat system over bittorrent or something alike.

  2. #22
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    Cool yeah the streaming thing isn't anything amazing, it simply prioritizes parts to come as close to a stream as possible. A stream supporting video player connects to utorrent for example and parts are prioritized that are within the requested buffer size of the player. I find it only really works well enough to stream something with lots of fast seeds. However there's all kinds of load balancing implemented by clients to ensure an even distribution of data across the pool of peers, while it's possible to request specific parts (as in streaming) there's clients such as Vuze that will actually block clients for making too many such requests, the streaming ability of utorrent has overall had a negative impact on the health of torrents as all the shared video files (especially brand new popular torrents) have an part availability bias towards the start of the file, damn near negating the usefulness of many peers in the swarm.


    I know that clients such as VUZE give you a chat functionality but I don't think that's part of the bit-torrent protocol, probably a custom type of bit-torrent packet marked as 'chat' that can be picked out. It's only going to be the same as a standard UDP chatting program but routed thru the shared bit-torrent port to save opening and routing a second port. There's nothing inheriant about the bit-torrent protocol that lends any advantages to chat as far as I can see and since a chat is normally one on one, a chat program that shares files with bit-torrent wouldn't really get any advantages, it'd work just fine thou, one seed, one peer.

    Fingers crossed you can find a pascal implementation of Bit-torrent of sufficient quality to use in your projects

    Writing your own bit-torrent seems like it would be more work than writing your own bit-torrent like protocol as you've got standards to adhere to and years of anti-leeching rules to adhere to unless you want your client blocked by other clients all the time.

    Definitely a fun project with lots to get your teeth into!
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

Page 3 of 3 FirstFirst 123

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Comodo SSL