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!