I been trying to make a Handshake request to the peer and although the I successfully getting the handshake response back.
For some reason data after the handshake response look weird.
Let me explain
Here is the handshake request
\x13BitTorrent protocol\x00\x00\x00\x00\x00\x00\x00\x00\x01G{\x96\er\xDB\x9Cd\x14O\xFCj\r/\x8D\xA7\xAE\xAE\xF166788486352714431784
and I'm getting a handshake response that look like this
\x13BitTorrent protocol\x00\x00\x00\x00\x00\x10\x00\x00\x01G{\x96\er\xDB\x9Cd\x14O\xFCj\r/\x8D\xA7\xAE\xAE\xF1-TR2840-e5rk4p002er6
Now here what making be baffled I read the next 200 bytes from socket
and I see this
\x00\x00\x00-\x14\x00d1:md6:ut_pexi1ee6:yourip4:o}\xD1)4:reqqi255ee\x00\x00\x00\x96\x14\x00d1:ei1e4:ipv616:$\x00a\x80\x01\x00\x00\xD0\x00\x00\x00\x00\x02\xA40\x011:md11:ut_metadatai3e6:ut_pexi1ee13:metadata_sizei166e1:pi51413e4:reqqi512e11:upload_onlyi0e1:v17:Transmission 2.
Assuming \x00\x00\x00- is the length of the (according to message structure of Bittorrent)
and "\x14" is the message_id = 20
But looking at the bittorrent protocol specification I fail to find a message with ID 20
I'm kind of stuck here and don't know where to proceed any help will highly appreciate.
The remote peer is showing non-compliant behavior. It is sending a extended handshake even though you have not signaled the capability in the reserved bitfield.
-TR2840-
This indicates that it is transmission 2.84. If it also occurs with current transmission versions I would report a bug to them. If it only occurs with old versions I would not bother handling this situation and just drop the connection.
Related
I am assuming that after finding peers using that Infohash you send handshake messages until one peer establishes a connection. But I can't seem to find any packet in Wireshark that has the metadata in it. If possible can you show me how a metadata query looks like?
The only thing I've found about metadata was bep 9 but it was kinda hard for me to understand and I didn't find anything in Wireshark similar
You already found the relevant BEP 9. To implement it you first have to implement BEP 10 and then check the extension header whether the peer supports BEP 9 and if it does send a series of extension messages with the appropriate negotiated IDs carrying a metadata request message.
You should be seeing the extension handshake message in most bittorrent connections since many clients support it. You're less likely to see metadata request/data messages (unless you explicitly trigger them in a client) because it's simply a less common operation than downloading the torrent payload.
My HTTP server needs to make sure that HTTP responses are delivered to the client.
I feel (and I will implement it so) that the most correctly way is to send the "I received the data" request from the client.
But I have a bit academic question:
Has the server some other means to detect whether the response delivered to the client or not (say due to the client's computer was evaporated by a direct hit of an H-bomb during data transmission)?
According to the node.js http documentation:
Class: http.ServerResponse
...
Event: 'finish'
Emitted when the response has been sent. More specifically, this event
is emitted when the last segment of the response headers and body have
been handed off to the operating system for transmission over the
network. It does not imply that the client has received anything yet.
After this event, no more events will be emitted on the response
object.
Also I did not find nothing better in the 'net' module documentation.
So it seems I can only know that my data is in the kernel buffer for transmisstion over the network.
Can I detect some errors at this transmission by Node.js means?
Can I detect some errors at this transmission by some easy-to-implement non-Node.js means?
Any links and thoughts that this is not an HTTP way or even not a TCP way are also appreciated.
The thing about TCP is that the receiver must acknowledge the fact that it receives every single bit of data. If that's not the case, sender keeps sending the pieces of data that receiver has not yet acknowledged to receive.
I checked out the Net module and I saw this interesting piece:
Event: 'end'
#
Added in: v0.1.90
Emitted when the other end of the socket sends a FIN packet.
I have no implementation idea for this but still, this might be useful for your case.
I've written an application that uses web sockets to communicate between the server and client. I'd like to handle the case where the client is out of date (too old), and thus would misinterpret/not appropriately handle messages. My thinking is that if the client is too old, I close the connection and send the appropriate status code. I read the spec and it seems that 1002 may be the appropriate code:
1002 indicates that an endpoint is terminating the connection due
to a protocol error.
However, I don't actually know what that means (if it actually refers to the web socket protocol, and thus a lower level error). Is 1002 appropriate for this, or should I be making a custom (application) close code in the 4000-4999 region as defined here: https://developer.mozilla.org/en-US/docs/Web/API/CloseEvent
The error code 1002 is for low-level WebSocket protocol violations. Like, the WebSocket message was a text message, but the payload contained invalid UTF8. You should not use that for the kind of situation. Errors 1002 are usually generated by the internals of a WebSocket implementation, not an application using WebSocket.
Now, in your situation, you have two options:
If the client can be identified as being "too old" already during the WebSocket opening handshake, you might fail the handshake using an HTTP Bad Request 400 already.
You might allow the handshake to complete, do some WebSocket message exchange determining the client version, and then close the connection (doing a proper WebSocket closing handshake) with an error code from the 4000-4999 range. Yes, that range would be appropriate. https://www.rfc-editor.org/rfc/rfc6455#section-7.4.2
The latter is more flexible and gives the client better feedback. In particular, JavaScript in browser will only get access to the close code (2), not any HTTP error in (1).
Another notable aspect: a conforming WebSocket implementation will simply not allow an application to trigger a close with 1002. The only close codes allowed for application use are 1000 (which is "normal" close) and 3000 - 3999 (app use, but registered at IETF) and 4000 - 4999 (app use, private unregistered).
I'm developing implement Bittorrent without using any library. I have tried to send a handshake message to a peer. I think this handshake would be symmetric by both side. But the peers sends a little weird handshake to me. For example, when I send the following handshake message to a peer,
\x13BitTorrent protocol\0\0\0\0\0\0\0\0<sha1 info hash><20byte of my peer-id>
I expect the handshake message like
\x13BitTorrent protocol\0\0\0\0\0\0\0\0<sha1 info hash><20byte of peer-id>
But I get
\x13BitTorrent protocol\0\0\0\0\0\0\0\0<sha1 info hash><20byte of peer-id><long stream of many bytes>
What does the long stream mean? any specs have never explained this.
Also, whenever I receive a handshake message, that stream size is always different.
If you are the initiator and has already sent your handshake message, the other peer answer with a handshake and can then immediately start to send normal bittorrent messages. That is the long stream you see.
Ok I have a WAMP installation with cakePHP under windows xp 64 bit. I am using a websocket PHP pluging with the latest node 8.17 and socket io version .9.13. None of my co workers seem to know what the problem is and i have been stuck for two weeks. I was able to narrow down the problem, but I have no clue on how to fix it.
After my cakephp plugin makes the request to a socket io server i can capture the authorization handshake request however according to the socket io protocol the response body should contain the handhshake id, the heartbeat interval, the timeout interval etc... Sometimes I would get the proper response however the majority of the times(like 90 %) of the time I would get a null body response but the headers return 200 ok response which throws an error in my application. Is there a way I can get consistant results. I am more that happy to post debug information so you can see what I am talking about. I read somewhere that it might be gzip compression problem but with the socket io update i believe that has been fixed.
Any help would be much appreciated!!!
Problem was with line 80 of mgcrea/cake_websocket plugin. For some reason although it was issuing the correct request it was receiving at intermittent response. When i overrode it it then solved the problem.