Age | Commit message (Collapse) | Author |
|
This exposes problems with keepalives:
exsample: sendWakeup: resource exhausted (Resource temporarily
unavailable )
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Fix tracker interval timeout: threadDelay use argument is microseconds
while tracker response is seconds.
* Fix stopped request: tracker might response with empty body.
|
|
* Annotate all required fields as strict. These are always used and
there is no reason to keep them lazy.
* Augment user errors with location.
|
|
|
|
|
|
|
|
|
|
|
|
Again, the problem is that one function returns errors in two different
ways: Either and IO exceptions. It's better to just throw exception in
either case.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We could provide better api this way. Also this refactoring should
reduce compilation time.
|
|
|
|
|
|
|
|
HTTP client functions throws an exception. If we unable to decode result
we return BEncode.Result.Left. So user of this function should check
both kinds of errors and this complicate usage. Instead of this we throw
IOException too.
|
|
|
|
stringBufferOp is defined in terms of strictBuffer op. So we previously
we have convertion from strict bytestring to string and then manually
pack string back to strict bytestring to with BC.pack. We could avoid
this unnecessary convertion by just using bytestring streams.
http://hackage.haskell.org/packages/archive/HTTP/4000.0.9/doc/html/Network-BufferType.html#v:stringBufferOp
|
|
Also add encoding tests for torrent module.
|
|
We need some internal functions in tests and benchmarks, so it's better
to just use CPP for this.
|
|
|
|
I do not expect that this modules will grow later, so they are merged
with Network.BitTorrent.Peer now. We also avoid one "reexport only"
module this way.
|
|
|
|
It seems like 'network-bittorrent' is too long and annoying: everyone
knows that bittorrent is a network protocol and there is no purpose to
prefix it with 'network'. Moreover hackage do not have package with
the our new name.
So I think just 'bittorrent' is a more suitable name for the package.
|
|
|
|
|
|
This is a bit faster and pretty!
|
|
This allow to provide better interface.
|
|
There are several reasons for this:
* IntSet is stored in ordinary heap, while ByteStrings in pinned memory;
* Our IntSet's should be much faster 90% time. (in typical BT client)
Hovewer in worst case IntSet is slower, but difference should is not
so big. (We should measure this although)
* It's pure, tested, error-free and much more convenient.
Moreover we have kill a lot of ugly code!
|
|
|
|
|
|
|
|
|
|
|
|
|