Stitching DHT and Torrent Client together - java

I have two java libraries.
One connects to DHT and can successfully download torrent files.
And the other which downloads the actual data associated with the torrent.
The torrent client library expects an announce or announce-list section in the torrent, and does't understand the 'nodes' entry.
The question is how do I alter the torrent client code to understand the 'nodes' section of a torrent file.
OR
How do I calculate a tracker URL from a set of ip:port DHT peer addresses?
I could just guess the url by guessing a port number and appending /announce onto it.. but this surely isn't right?
Does anyone know how this works?

For DHT-only operation you do not need an announce URL. If the library itself expects one you can insert a dummy url, the format dht://<infohash in hex> is common, but it does not matter, as it won't be used.
The DHT part on the other hand does not require the nodes to perform a lookup, it simply operates based on the infohash of the torrent. The nodes can optionally be injected into a dht client for bootstrapping, e.g. by executing a ping on them, but that should not be needed if it already is bootstrapped.
Once the DHT client has done its get_peers and announce lookups the peer lists can be injected back into the torrent client.
Since you're using my library: You can use PeerLookupTask to read a torrent peer list from the DHT and AnnounceTask to add your torrent port to the list. The obtained IP and Ports have to be passed to the torrent client. The GetPeers CLI command contains an example how to use the first part.
There also are utility methods that should cover common use cases.

For an alternative I may recommend you to see Bt, which is a Java 8 BitTorrent client and already integrates with the8472's mldht: https://github.com/atomashpolskiy/bt

Related

Implemeting a basic FTP client in Java

I want to write a FTP-Client in Java with a restriction: No advanced libraries (e.g. .ftp, .url etc.) allowed.
How do I implement a method to print the current directory, change directory and download a simple .txt-file?
You can start by reading up the RFC governing the FTP protocol. With that you can get an idea on how the FTP protocol works, how it sends commands, expected responses etc.
You can find a link here: https://www.rfc-editor.org/rfc/rfc959
Aside from that you can have a look at this GitHub repository. In there you'll find a simple FTP client that I wrote back when I was in uni. The FtpConnection class implements most of the commands you'll need to do your job.
Have a look at it and how these are used.
https://github.com/Kortex/Simple-FTP-Client

Selective downloading of torrents via webseeding

I serve up files from a Jetty webserver which presently get downloaded via regular HTTP GET.
However, I am interested in a P2P model where users can download files via the webseeding. How would this be implemented in the context of a Jetty server with libtorrent?
Second, I dont want to "seed" ALL files on the Jetty webserver forever, instead I only want to be able to seed files "on demand".
For example rather than blindly seeding a torrent, I would like to have the file available for demand IF a request comes in for it (via GET or webseeding or whatever) - upon which it can be "seeded".
I want to seed or upload on demand because I have a multitude of files and do not know if I will be able to seed tens of thousands of files concurrently. Btw would anyone know what the upper limit is for number of files which can be seeded concurrently?
The relevant documentation about the libtorrent part is here: http://www.rasterbar.com/products/libtorrent/manual.html#http-seeding and the specs are http://bittorrent.org/beps/bep_0019.html and http://bittorrent.org/beps/bep_0017.html (both being supported by libtorrent, as "url seeds" and "http seeds").
IIRC, BEP19 (webseeds, or urlseeds) is rather straight-forward from the server POV, and you don't need to do anything special there - you just serve the files as you would do for a normal HTTP requests for that file (so, the second part of your question doesn't quite make sense here).
With BEP17, you rather use a unique http endpoint, and pass it get parameters to specify what the client wants (which for example allows for better throttling control and range selection) (eg: http://example.com/seed/?info_hash=X&piece=Y&ranges=Z).
This second approach is more flexible if you intend to have more (programmatic) control over what is downloaded, but obviously requires a lot more code to write to handle the requests though.
Again, from the server POV, this is not that different from regular HTTP transactions, and there is nothing special about "seeding" here. You just serve files (each with its own url, either directly, or via a handler).
A for the metadata part, with BEP19, you add a "url-list" extension (with the full url of your file: http://example.com/seeds/SOMEFILE.txt - watch out for multi-file torrents), whereas BEP17 uses the key "httpseeds" (with your endpoint, eg: http://example.com/seed/).
Depending on whether your Jetty also handle metadata generation or not, you might prefer BEP19 over BEP17, for your urls to be more predictable / the metadata generation to be simpler...
Hope that helps.

How to verify data integrity between client-server connection?

I recently developed an online multiplayer game and it's working fine. There's a central server handling TCP connections with clients, and they both receive and send data.
Is there a way to verify that the data sent hasn't been modified before the receiver reads it?
Does a TCP connection handle it in some way? If not what is the best way (not asking for code) to implement it?
By now I came up with those ideas:
Modify the data sent adding some sort of verify-value, such the packet length.
When a packet is received, ask the server to send it again and verify if they are equal.
I searched for a common used solution but couldn't find much.
Encryption should be my last option.
Edit
For a simple way to achieve this:
MD5
Wikipedia
Example
SHA1
Wikipedia
Example
SSL
Wikipedia
Example
Agreed with Bart, you may want to look at using a Hash method for data verification.

Can hardware information by obtained on a device that interacts with a Java servlet?

Is a way to gather hardware information to uniquely identify a certain device (not a category) that makes requests to a Java servlet ? I searched for this, but I don't think there is a method ( "user agent" header can be used for some information, but that only identifies a certain set of devices and it is not enough).
This information is not available anywhere in a HTTP request. The remote address (client IP) and the user agent (the string which the browser pretend to be) are the closest unique identifiers you can ever extract based on a HTTP request. Even then, this information is not reliable. The client can for instance use an anonymous proxy. The client can for instance have changed the browser's user agent string.
You basically need to collect this information in the client side and then send it to the server side as request parameters yourself. You're in turn however limited in the available ways to collect this information. JavaScript for example doesn't allow this due to security reasons. Your closest bet is a signed(!) Java Applet or Web Start application. This allows you to let the client download some Java code and execute it locally. But this is also not always reliable. The client can for instance hack the applet/webstart code and/or tamper the HTTP traffic between the applet and the server.
Another way is to just introduce a registration/authorization/authentication system wherein the client need to supply an unique identifier itself by a valid login. This is not only simpler, but also more robust.

My program needs to access information (key/value) from my hosted server. What web architecture would be best for this?

My program needs to download object definitions (basically xml files, maybe binary files) on demand via the net. The program will request objects from my server during runtime. The only thing the program has to send the server is a string that identifies the object it needs (e.g. RedCubeIn3DSpace23). So a basic Key, Value system. My app also has to have some basic authentication mechanism to make sure only legitimate programs access my server’s info. Maybe send the license number and a password.
What is the best way to go about implementing this? I have 0 web knowledge so I'm not sure exactly what technologies I need. I have implemented socket programs in college so maybe that is what I need? Are there frameworks for this type of thing? There could be thousands of users/clients simultaneously; maybe more but I don’t know.
One super important requirement is that I need security to be flawless on the server side. That is, I can't have some hacker replacing object definitions with malicious one that clients download. That would be disastrous.
My first thoughts:
-Set up an ftp server and have each xml file will be named by the key value. Program logs in with its product_id and fixed password and just does downloads. If I use a good ftp server, that is pretty impervious to a hacker modifying definitions. Drawback is that it's very non expandable nor flexible.
-RESTful type system. I just learned about this when searching stackoverflow. I can make categories of objects using URL but how do I do authentication and other actions. Might be hard to program but is this a better approach? Is there a prebuilt library for this?
-Sockets using Java/C#. Java/C# would protect me from overflow attacks and then it is just a matter of spawning a thread on each connection and setting up simple messaging protocol and file transfers.
-SOAP. Just learned about it while searching. Don't know much.
-EC2. I think it (and other?) cloud services add a db layer over it.
That's what I can come up with, what do you think given my requirements? I just need a little guidance.
HTTP seems a better fit than ftp, since you only want to download stuff. That is, you would set up a web server (e.g. Apache), configure it for whatever authentication scheme you need, and have it serve that content.
SOAP is clearly overkill for this, and using raw sockets would be reinventing the wheel (i.e. a web server).
I'd do security on the socket level, using HTTPS. That way, the client will verify the identity of the server prior when establishing the connection, and nobody can intercept the password sent to the server. Again, a decent webserver will support this out-of-the-box, you just need to configure it properly.

Categories