Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue,Todo about IPFS #289

Open
LNTakeshi opened this issue Apr 15, 2018 · 2 comments
Open

Issue,Todo about IPFS #289

LNTakeshi opened this issue Apr 15, 2018 · 2 comments

Comments

@LNTakeshi
Copy link
Contributor

LNTakeshi commented Apr 15, 2018

#285 に関するIssue,Todoです

  • beatorajaが異常終了するとipfsのdaemonがずっと残り続ける
    • このような場合や、beatorajaとは別にdaemonを立ち上げた時に何度もdaemonを立ち上げようとしてしまう
      • ipfs shutdownみたいなコマンドがあれば良いが、無い
  • ipfs(.exe)の同梱
    • ファイルが大きすぎる、Windows版/Linux版がある、アップデートが必要→各自でInstallが楽
  • ダウンロード開始までが遅い
    • 恐らくファイル保持者が増えれば短縮されると思う、しかし現状では遅すぎる
    • パブリックゲートウェイ利用である程度改善された
  • BMSONについて
    • AppendIpfsのハッシュの中身がファイルの場合、現状は(Hash値).bmsというファイル名で作成するのでbmsonは無理
    • ディレクトリとしてダウンロードするとファイル名が保持されるので、そちらの方法でbmson差分は自動適用できる
  • EventTable
    • "BMS(ON)は変更しないが、Movieの差し替え"などの例が考えられるので、これに対応しないといけない
    • 最終更新日時とか、バージョンなどがEventTableに必要かもしれない(更に楽曲データベースにもこの情報を保持する必要がある)
@dtinth
Copy link

dtinth commented Apr 15, 2018

Sorry for English… You can reply/discuss in Japanese.

  • EventTable

    • I think we don’t need to keep track of 最終更新日時 or バージョン because IPFS is content-addressed. This means “same content = same hash” and “different content = different hash”.

    • For example, if I add a movie file, I need to run ipfs add on the folder again. I will get a new IPFS hash.

      Example:

      • Before (no movie):

        > ipfs add 422
        ...
        added QmVUCNEebVF2f439qh8dNyGw6LbqX8KMxCGi9vc8ZScnMH 422/p0x0009437D.ogg
        added QmccvPVcFFCwDWHePQ1hMqDY5ZbiaUHNraPKpiT3rLTjmK 422/p0x0009478A.ogg
        added QmZCiLMf1xX4PcrrRUUc81w6NDvFQzRurtVShsHj8bjgLR 422/s0x00000000.ogg
        added QmTe4C72xQED2kSL881sAKsQ67KAb2EUJcWPref3LzbzgF 422
        
      • After (movie added):

        > ipfs add 422
        ...
        added QmXgLNkUTLprCzo4r7mm2Xko8ffbPLGvKFvpkpzihboa3d 422/b0x01629f51.mpg
        added QmVUCNEebVF2f439qh8dNyGw6LbqX8KMxCGi9vc8ZScnMH 422/p0x0009437D.ogg
        added QmccvPVcFFCwDWHePQ1hMqDY5ZbiaUHNraPKpiT3rLTjmK 422/p0x0009478A.ogg
        added QmZCiLMf1xX4PcrrRUUc81w6NDvFQzRurtVShsHj8bjgLR 422/s0x00000000.ogg
        added QmeDdnCpAMceEQcXxBS3j5E5FZMtDuFLxGXJR42UyVYcvX 422
        
    • I update the event table and change
      "ipfs": "/ipfs/QmTe4C72xQED2kSL881sAKsQ67KAb2EUJcWPref3LzbzgF"
      into
      "ipfs": "QmeDdnCpAMceEQcXxBS3j5E5FZMtDuFLxGXJR42UyVYcvX".

      • I can keep "ipfs_diff" unchanged because BMS file is not changed.
    • When I play the song again, maybe run ipfs get /ipfs/QmeDdnCpAMceEQcXxBS3j5E5FZMtDuFLxGXJR42UyVYcvX.

      • If I already downloaded the old version, this will be very fast, because only the part of tree that’s different needs to be downloaded.

@LNTakeshi
Copy link
Contributor Author

LNTakeshi commented Apr 16, 2018

IPFS folderの中身が変わると新しいIPFS hashに変わる仕様は上手く利用したいですね。
ただし、beatorajaでは現在md5/sha256を利用してTableのBMSを参照しているので、(例えばmovieを変更した場合)md5は変化しないので、例えIPFS hashが変わったとしてもBMSは持っているものとして扱われます。
そこで、将来的にはdatabaseにmd5/sha256に加え、IPFS hashも保存しておく必要があるかなと思います。(現在はディレクトリ名で代用していますが)
こうすることでdatabaseのIPFS hashとTableの"ipfs"が異なれば再ダウンロードが行えるようになります。

この場合、BMSに修正が入るケースではmd5に加えIPFS hashも異なるため、Tableの"ipfs"を書き換えただけでは別のディレクトリが作られてgetが行われると考えられます。
そこで、EventTableで利用する際には、"org_md5"に修正前のBMSのmd5を含めることで旧ディレクトリが参照出来るようになり、上書き適用出来るかなと考えています。
DifficultyTableでは"org_md5"に含むBMSを持っていると"ipfs"を無視して"ipfs_diff"だけをダウンロードするのに対し、EventTableでは"md5/sha256"に一致するBMSが未所持で且つ"org_md5"に含まれるBMSを持っている場合、該当するディレクトリに"ipfs"を上書き適用するのが良いかなと思います。

これらすべての場合で、databaseにipfs hashが含まれない場合(=ユーザーがIPFSを利用せずにダウンロードした場合)はどのipfs hashに該当するファイルを持っているのか不明であるため、無視するべきかなと思います。

(Google Translate was used in part)
If you change the contents of the IPFS folder, I would like to make good use of the specification that changes to the new IPFS hash.
However, since beatoraja currently uses md5 / sha256 to refer to BMS of Table, md5 does not change (for example, when movie is changed), so even if IPFS hash changes, possessing BMS It is judged to be.
So in the future, I think that it is necessary to store IPFS hash in addition to md5 / sha256 in database. (Currently it substitutes for directory name)
By doing this, you can re-download if the IPFS hash of database and "ipfs" of Table are different.

In this case, when the modification is made to BMS, IPFS hash also differs in addition to md5, so even if you rewrite "ipfs" in the table, another directory is created and get is assumed to be executed.
So, when using it in EventTable, I think that we can refer to the old directory by including md5 of BMS before modification in "org_md5", so that overwriting can be applied.
DifficultyTable ignores "ipfs" and downloads only "ipfs_diff" if you have a BMS included in "org_md5", whereas even if you do not have a BMS that matches "md5 / sha256" in EventTable, If you have a BMS that included in "org_md5", I think that it is better to overwrite "ipfs" over the corresponding directory.

In all of these cases, if ipfs hash is not included in database (= if the user downloaded without using IPFS) it is unknown which ipfs hash the corresponding file is, so it should be ignored I think whether it is.

By the way, Thanks to you I was able to know about IPFS.I am grateful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants