レス数が1スレッドの最大レス数(1000件)を超えています。残念ながら投稿することができません。
あれくま作業中 29作目
-
朝とか週末にプログラム書いたりなんだりしています
↓画面転送アプリPetraとかデスクトップマスコット配布中
ttp://arekuma.s300.xrea.com/
ぴあきゃすリメイク作業はじめました。
-
ttp://dl.dropbox.com/u/3160952/memo.txt
いまかいてるめも
-
昔C#に移植してからだと分かりやすくなるかな？って思ってやってたけど、
移植の段階で挫折しまうま・・・
-
PEERCASTがむかしのでPCPがいまのプロトコルだった気がする
-
お、頑張って読んでるね
-
ところでこれって再設計し直す感じ？
さすがのあれくまたんでもすごい時間かかりそうね
-
てかあれくまさんはテキストエディタで読むんだな…
Visual StudioとかEclipseじゃないと俺はもうだめだわー
-
それなんのソース？
今開いてるのIM版なんだけどうちの環境だとwriteAtomsが3339行目にあるなあ
-
ピアキャスのソースディスる配信はじまってた
-
未だ使われない秘められた潜在能力の数々
-
あーリメイクやめよ
ステーションなんてなかった
水子供養しないと
-
ChanHitList自体は連結リストの要素みたいになってて
その要素1個づつにチャンネル情報を持ってるChanHitが格納されてる
って感じなんだなー
-
自分も好きだからこまる
そして捨てる
-
つかこんなのはSTL使ってくださいといいたいね
-
皆8年前のプログラム使ってるのか…
-
確かに読みにくい気はするけど、これを作り上げたのは普通にすごいと思うわ
ピアカス作者は今何してるんだろ
-
多分作った当時は学生で普通に就職したというのがありがちなパターン。
てかこのソースは学生が勢いで書いたソースって雰囲気がばりばりするｗ
-
おお おもしろそうなことやってますね
peercastってぐぬーてらのプロトコルなんだっけ?
-
そうなのｗｗｗ初めて知ったｗｗｗｗ
-
そうなのかー知らんかった
-
俺は任天堂っていうのはスラドで知ったな
-
バケツリレー以外の方式ってどんなのがあるの？
-
ttp://homepage2.nifty.com/kamitoba/report/creater/goddard.html
あった
-
ジャイルズ・ゴダード
■主な代表作
タイトル 機種 発売日 役割
スターフォックス SFC 93.02.21 プログラマー
ワイルドトラックス SFC 94.06.04 プログラマー
スーパーマリオ64 N64 96.06.23 マリオフェイスプログラム
1080°スノーボーディング N64 98.02.28 メインプログラマー
巨人のドシン GC 02.03.14 プログラミング
この人？
-
ストリームだからファイルバラバラに貰ってくるのはちょっと無理があるんじゃね
-
なるほどそうなのかー
-
でもそんな仕組みを1から作るのすげー大変そう・・・
-
任天堂というかレア社のゲームか？
-
次世代peercast制作会議でしたか かっこええ
-
消失ドメインババァ出たーｗｗｗｗｗｗｗｗｗｗｗｗｗ
-
ピアキャスって直下取ってバッファ詰めても結構ラグあるんだよな〜、
あれ配信者側の設定でどうにかできるものなの？
-
次世代のコーディングスタイルに書き換える配信
-
これもリファクタリングと言ってもいいの？
-
ばらばらでも、例えば１KBづつ、周りから貰えばストリームでも可能だろうね
バラバラだと、一人落ちても、他の人に要求すればいいし、
構造自体、柔軟だから、有益なノードを緩やかに上流付近に移動させるのも比較的容易
-
aquaskkの入力モードをカーソルのとこに表示するの邪魔くさくね？ｗｗｗ
-
aquaskkでターミナル上でもCtrl Jで日本語変換に突入するのってどうすればいいんだっけ?
前はできてたと思うんだけど再インストールしたら設定を忘れて改行しかされなくなってしまった
と どさくさにまぎれて聞いてみる
-
そっか 設定してなかったか
関係ないこと聞いてごめんw
-
IDEで確認したけどChanMetaほとんど活用されてないね…
fromMemは1箇所使ってたけど使った結果は捨ててるし。
あえて言えばoggの処理で定数を使ってるだけだ
-
ド素人な俺は、恥ずかしながらこんなこんなもん作りながら
読もうと試みてたｗ
ttp://ohaoha.ath.cx/p/ohaoha133795.zip
-
どうでもいいけどピアキャスのポートチェックが自己申告なのはどうにかならないの？
以前俺が活用してたけど穴すぎだよ
-
>>562
活用するなよｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
-
>>561
このアナログ感、ICFP時の猛者だな。
-
Firewalledとかそういうフラグがあるからそれfalseにすればポート開いてる事になるよ
-
どっかにfirewalledってパラメータがあってそこを固定にしちゃえば
ポート塞がれてても緑になれるんですよね
-
なんという悪ｗｗｗ
-
これどう考えても1から作った方が早いよね。改訂版作る時は
-
ちゃんとソース読んでる人結構いるんだね。
さすがあれくま配信に来る人は違うで
-
どんなもんの頻度で必要になるかわかんないけど
場合によってはチェックしに行くようにしたらそれはそれで別の問題が出そうだね
-
あれくま配信にはいろんなプロがいるという噂
-
環境依存の部分はどのくらいあるんだろ
-
前とあるP2Pを作ったときにポート0を自己申告以外でちゃんと判定出来るような
プロトコル考えたけどPeercastと互換性なくなっちゃうしなぁ。もうそのへんは放置で
いいんじゃないのかしら
-
例えばリレー数nに応じてc/nくらいの確率でチェックしてやるだけでも十分だと思うけどね。そうすれば負荷一定だし。cは定数
-
てきとうな確率でチェックしにいくのは機能するかもしれんね
-
そんなもんなのか
そういやプレイヤーは含まれてないもんね
-
ポートチェック自体はYPがやってるのと同様に調べればいい訳だからなー
-
特にリレーに問題が出てそうにない状態ならチェックする必要も無いだろうし
するしないは手動で出来るようにしとけば十分かもね
-
あー俺が考えたのもそんな感じかなぁ。自分のノード情報の拡散は自分から接続、
データの送信は相手から接続と分けてやればポート0が理論的に居なくなるんだよね
-
tit-for-tatでいいやって思ったけどP2Pじゃ機能しないらしいね。give-to-getじゃないと上手くいかないらしい
-
生命キャストって防止できるようになりますか？
-
パケットばらばらにもらうやつの利点は、偽装緑も問題ない点なんだよね
ツリーリレーの場合、偽装を見破るのは非常に難しい
-
逆にコードが綺麗になると悪意ある改造をしやすくなりそうな気もするｗ
-
生命キャストは架空のChanHitオブジェクトを大量に作ってるだけだね
-
対応はしやすくなるだろうから綺麗にしとくに越したことは無いなｗｗｗｗｗ
-
ケルクホフスの原理的にそれはよろしくない
-
配信者のピアカスで、リレー情報取得要求に来たIPを記憶しておいて、下流から来た
リレー情報と比較するってのはどうかな？っと適当書いてみる
-
ChanHitListにgetTotalListenersとかgetTotalRelaysがあるからそこで
連結リストの数＆連結リストの中で視聴中の要素の数を数えてるだけだから
架空のChanHit作られちゃうと正直対策は無理なんだよねえ。
一応対策みたいなのも考えたけどこれまたPeercastのプロトコルと互換性がなくなってしまうｗｗｗｗ
-
ポート０の排除より、
リレー管理の運用がしやすくなるような何かがあるのが一番いいと思う
-
この前公開鍵秘密鍵の方式知ったんだけど、あれ良く出来てるな〜と思った
-
590から589に飛んだぞｗｗ
-
「あ、あれくまさんっぽいのがつないでる！BAN！」とか
-
いや冗談を真面目に取らないでほしいんだけど・・・ｗｗｗｗｗｗ
-
プロトコル一新して、実帯域に応じて動的にツリーを再構築するとかだな
それ言うならツリートポロジーはとっととやめてメッシュトポロジーにすべきなんだけど
-
中間ノードがBAN情報偽装して吐けたら余計面倒な機能になるな
-
鏡ツールのリザーブとか？
指定したIPを優先的に接続できるようにするみたいな
-
直接命令送るんじゃなくって命令取りに来いって命令を出して、
命令を取りに行くようにすれば悪用されないんじゃないかな
-
公開鍵で認証付ければ偽装はできなくなるけど正直そこまでやる価値があるかというと…
-
いや命令出せるのは配信者だけ
-
枝の形がどうなってるかとか、
自分が何層目についたとかの情報が流れてくるだけでも、
自律的な管理の役に立つとおもう
ちょっと見て切りたいときとかに直下近くに付きたくなかったりとか。
-
デスラー総統だから下流に回りたいって人の目安にもなるかもね
-
でも各ノードはツリートップの配信者の情報持ってて直接叩きにいけるんじゃないの？
-
つーか手動管理とかアホらしすぎるよな
-
光マン待機モードみたいのはあってもいいかもしれない
直下だけ帯域制限して、その下は勝手に繋げみたいな
ってもうある?
-
下に23人も憑いてるやだこわい
-
まあプロトコルの改善は小悪魔の宴がある程度できてからの話だよな
まずはオリジナルに追いつかないとｗ
-
コードネーム小悪魔になったの？
-
これあったらいいな、は既にある法則
-
帯域制限手動管理だと戻すの忘れてて文句言われてる人たまにみるからさw
-
直下紫を弾くようにしてる生意気な過疎配信者には問答無用で偽装緑
-
帯域はyp側と連携したらできないこともないと思う
Peercastだけで帯域判定は・・・うーんぱっと思いつかないな
-
直下の接続時間を考慮して、そのノード以下の接続数が、他の直下ノードに比べて少ない場合、
偽装緑だと判断するっては１つの方法かもしれない
バッファるノードの子供は、他につなぎに行くからね
-
YPの制限設定ならPecaスタータだっけ？あれでも自動切り替えは実装できそうだしな
-
ピアカスって光の戦士とデスラーってどうやって判別してるの？
-
帯域は単純にパケットロス出してるノードの情報を集めてベイズ推定でもすればいいんじゃないの？
-
光の戦士ってどれぐらい待機するのがいいんですかね？
-
>>615
そこは配信者が判断すれば良いんじゃない？
-
デスラーを低画質リレーツリーに隔離とかできないかな
-
善玉ノードが自分が大丈夫かどうかの判定はそんなに難しくないんじゃない？
スループット自体は今でも出してるわけだし
悪玉ノードの対策はまあ諦めていいんじゃないかなｗｗｗｗｗｗ
-
自分の偽装緑は、バッファ出したときの▼マークで知ればいいのでは？
-
yp側の帯域制限って、帯域満たない奴に対して配信者の直アド隠すだけだよね？
プレイヤーで直アド叩けば見れるような。
-
YPの帯域測定と連携できないの？
-
いや、受信側の下り帯域が足りてなくてもナブラるからアウト。
わざと下り帯域絞る奴が出てくる
|
|
掲示板管理者へ連絡
無料レンタル掲示板
