LMD wrote:I don't think this is a working media server, judging by the code (https://github.com/Lejo1/minetest-media ... dex_mth.py)
The actual media server spec is a bit like the following :
1. Minetest client requests media corresponding to MD5 hashes (checksums), got nothing to do with filenames, using POST
2. Server checks which hashes it has and servers them
I have no idea what you are doing there, especially with "hex_decode". Have you tested to make sure that it's actually working ?
> And it's even faster
Nothing but some claim, only justified by a few pings... I think that it's hardly possible to be faster than my Java or sofar's Go implementation...
Lejo wrote:Sure it works don't judge things you haven't tested!
It generates a static index.mth file containing the signature, version and the hashes.
LMD wrote:> Your system needs to calculate what to send
Of course it does ! There is no other way, AFAIK. Probably old protocols. That way the client can know which files your server can serve. So there won't be that much failed requests. It likely saves you LOTS of time.
Also, the calculations I do are extremely efficient. Binary searches and such. Number of hashes * binary lookup. That's not alot. My implementation does this in, huh, no idea, but extremely fast. And this only needs to be done a few times (when index.mth is requested).
Lejo wrote:For all other remote media services you need a paid root server.
But you can everywhere get a simple static webserver where you just need to upload the medias.
You don't need to install complex programs you just generate the index file.
LMD wrote:Ah, now I know why I have been mislead. I thought you were just giving file names. You aren't. Your file names aren't the hashes.
LMD wrote:But this means that the given source code is not complete. There is no easy way of adding media; it needs additional shell scripts and stuff.
LMD wrote:My impl is also easy to use (as easy as running a JAR with arguments) and automatically retrieves media which does not need to be in any specific format (normal Minetest subgame/mod folders will all work).
sofar wrote:He can read code. He can see that you're using `filename.decode("hex")` which does not generate sha1sums. So clearly, it is an incorrect implementation.
sofar wrote:Your implementation is not functional. The only reason MT clients don't complain is because the client implementation has proper fallbacks. You don't understand the protocol and are not properly testing it yourself. Hint: watch the web logs, and hexdump your index.mth.
sofar wrote:He is sending each MT client that connects an 875KB file. Every, single, client, Every time they miss 1 media file. My implementation would only send ~30 bytes or so if only 1 file is needed from the server.
sofar + Linuxdir wrote:I ... don't understand why people are making inadequate solutions if a feature rich, open source and efficient implementation exist. A static index.mth is a ridiculous way to waste internet bandwidth and make MT clients do more work for no reason. Especially for a public service.
You people should support existing projects instead of fiddling around with this crap :D
sofar wrote:This is far worse than sfan5's shell script, which actually does this correctly. Your code is non-functional.
LMD wrote:This is (obviously) not true. I would rather say the exact opposite is true; the more media a media server (that's its purpose) can serve, the faster the process.
sofar wrote:This conclusion is garbage because you did not account for the amount of raw bytes transferred(rx/tx) to each client.
sofar wrote:Lejo1's implementation forces each client to download 875Kb of data from the remote media server, while much, much less is needed.
sofar wrote:A proper comparison would also account for speed of connection.
Lejo wrote:The goal of the server is NOT to be faster!
The goal is to be simple and free to setup, like my way.
Maybe it’s a few ms slower but that’s not much.
Lejo wrote:The goal of the server is NOT to be faster!
The goal is to be simple and free to setup, like my way.
Maybe it’s a few ms slower but that’s not much.
Festus1965 wrote:But as like the only one server-master cheating ping, only one media-server is also cheating as it depends on the location of gamer if it is better or not.
sofar wrote:Ping is almost entirely irrelevant for the remote media protocol.
https://en.wikipedia.org/wiki/SHA-1 wrote:typically rendered as a hexadecimal number
sofar wrote:You may as well have not even made the python script, and remove the index.mth file (or put the 6-byte header in it). It would work just the same, since it contains garbage data.
INFO[Main]: Client: Failed to remote-fetch 4570 files. Requesting them the usual way.
Lejo wrote:Could you please maybe tell me whats wrong instead of telling it's garbage...
Lejo wrote:Ah I finally found sfan5's script
It does the same just that it gets the sha1-binary using openssl dgst -binary -sha1
user@pc:~/minetest-media$ openssl dgst -sha1 media/0000d50cfbb0f91790b80abccdd0a670e6146d8b
SHA1(media/0000d50cfbb0f91790b80abccdd0a670e6146d8b)= 0000d50cfbb0f91790b80abccdd0a670e6146d8b
LMD wrote:> it is a lot faster then generating the hash.
Maybe, but as already said before, you don't provide a proper way to add stuff.
Also, current implementations only generate hashes on startup (which is a pretty fast thing btw).
LMD wrote:> what's wrong in your opinion
Your media server is static. That's the problem. It's some "outdated" (at least IMO) method. You send all the data, which is often not required. Calculating what to send is also extremely fast.
Furthermore, (not sure whether sofar would agree with me on this) you are using GitLab / GitHub Pages. This likely makes the media sending process slower I think. Such services are sending unnecessary headers. Imagine sending thousands of 16x16 pixel art images. The images are likely only 256 bytes ore less if indexed colors are used. Your headers however can be larger than the actual media you are sending.
Furthermore, it also provides a neat way of providing arguments (such as port) and scans the media on initialization, which makes adding easier.
Lejo wrote:@sofar So last time I try to explain you how it works. I'm not sure if you don't understand or if you don't want to understand...
sofar wrote:I literally gave you the answer, using your own words. The answer to your problem is right there, yet you fail to see it.
I've implemented a correct implementation of the remote media protocol. You have not. Maybe you should read my implementation, or even LMD's implementation, which is also correct, but I understand it 100%. And your implementation isn't.
Hint: this line is (very) wrong: https://github.com/Lejo1/minetest-media ... _mth.py#L8
Return to Minetest-related projects
Users browsing this forum: No registered users and 0 guests