Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upQuestions about the WebTorrent protocol #1572
Comments
This comment has been minimized.
This comment has been minimized.
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
This comment has been minimized.
This comment has been minimized.
We don't send one specific chunk size, so I would not rely on receiving any specific size. Node.js streams by default have an internal chunk size of 16kb, I believe. But that doesn't mean that our calls to send() will necessary always be 16kb.
It's fine to ignore unwanted offers. The remote peer will close it's end of the connection after a timeout.
This is totally fine to do.
You can announce before the interval expires, but it's possible that the tracker server will ignore you / ban you temporarily (it's up to the tracker) if you contact them too frequently. |
This comment has been minimized.
This comment has been minimized.
|
I'm closing this issue since there's no bug to fix here, but feel free to continue discussion! |
What is the maximum SCTP chunk size? WebTorrent appears to be sending each BitTorrent message in two chunks, but I've been sending it fixed-size chunks of 4kB and it groks them. Knowing the maximum chunk size that WebTorrent will send would be useful for sizing buffers.
How do I reject an offer from the tracker? Do I just ignore unwanted offers? Right now, I'm simply closing the WebSocket connection when I've got enough peers, is that the right thing to do?
If I want to generate new offers, am I allowed to send a new announce before the interval expires? It seems inefficient to generate offers before they are needed, with all the ICE traffic they cause.