נניח ש:

- רוצים להתחיל הפצה של iso גדול (600 מגה) דרך BitTorrent מ Seeder בודד שמחזיק את העותק
- כל המחשבים המשתתפים בתהליך הם בעלי אותו רוחב פס ל upload (למשל 10KB לשניה)
- כמות הצרכנים היא יחסית נמוכה (נגיד כ-10)

השאלה היא איך להבטיח אופטימיזציה של התהליך, ז"א שכל כמות המשתתפים יקבלו את העותק במינימום זמן בממוצע.

למשל: האם עדיף שכל ה 10 יהיו Leechers מההתחלה, או שעדיף שרק 2 יהיו Leechers ורק כשהם הופכים ל Seeders אז ה 8 האחרים יתחילו להוריד, או שה 8 צריכים להוריד כששני ה Leechers הראשונים הורידו 30% מהקובץ, או שעדיף שחצי יורידו בהתחלה וחצי יצטרפו אחרי יום וכו' וכו'.

בקיצר, מודל שיגיד איך נכון לבצע הפצה אופטימלית בהתחשב בתנאים שציינתי לעיל.

אם אתם מכירים פורומים מתאימים אנא המליצו (חוץ מפורום מתמטיקה בתפוז)...

קצת מידע למי שלא מבין על מה אני מדבר:

כתבה די בסיסית על הטכנולוגיה:

http://www.whatsup.co.il/modules.php?op=modload&name=News&file=article&sid=2522

רקע קצת יותר מעמיק על האלגוריתמים:

http://bitconjurer.org/BitTorrent/bittorrentecon.pdf

אני לא מתמצא בקטע המטמטי של העניין אבל המנוע של הביטורנט הפך להיות מיושן וצולע לעומת זה של emule . לפי המודל של ביטורנט שתיארת פה ייקח להוריד סרט באורך 700 מגה משהו כמו שלושים שנה...

האימיול עובד בצורה כזאת שגם אם הורדת 20 ק"ב של משהו , הם משותפים עבור כולם...
עכשיו נשאר רק לחכות ש amule הלינוקסאי המקביל יפסיק לקרוס ויהיה יציב ואז יהיה לנו סופסוף משהו טוב הרבה יותר מ ed2k ובטח שיותר טוב מביטורנט.

WolfSign :

עכשיו נשאר רק לחכות ש amule הלינוקסאי המקביל יפסיק לקרוס ויהיה יציב ואז יהיה לנו סופסוף משהו טוב הרבה יותר מ ed2k ובטח שיותר טוב מביטורנט.

ניסית פעם את mldonkey? מהיר יותר מ-emule (לפחות מניסיון שלי)

האמת שניסיתי לתקופה קצרצרה אבל לא התרשמתי...

דוביקס :

מי שיכול לענות על השאלה הזו הוא מישהו שיצליח למצוא בגוגל משהו שאני לא הצלחתי למצוא עד עכשיו או מישהו שיש לו השכלה גבוהה במתמטיקה, או מישהו שמכיר פורום של מתמטיקאים (חוץ מתפוז)...

מציע לך גם לשאול בפורום שפות תכנות של תפוז - סה"כ זאת בעיית אופטימיזציה ונתקלים בהמון בעיות מהסוג הזה במדעי המחשב.

WolfSign :

אני לא מתמצא בקטע המטמטי של העניין אבל המנוע של הביטורנט הפך להיות מיושן וצולע לעומת זה של emule . לפי המודל של ביטורנט שתיארת פה ייקח להוריד סרט באורך 700 מגה משהו כמו שלושים שנה... האימיול עובד בצורה כזאת שגם אם הורדת 20 ק"ב של משהו , הם משותפים עבור כולם... עכשיו נשאר רק לחכות ש amule הלינוקסאי המקביל יפסיק לקרוס ויהיה יציב ואז יהיה לנו סופסוף משהו טוב הרבה יותר מ ed2k ובטח שיותר טוב מביטורנט.

לפי הבנתי, דוביקס לא תיאר פה מודל, אלא שואל איך המודל נראה.
מניסיוני המועט עם BitTorrent הוא גם מתחיל לשתף ישר כשאתה מתחיל להוריד את הקובץ. לפי ניסיוני, הוא יותר מהיר מאימיול.

קרא על מצב ה superseed של הקלינט הניסיוני כאן

WolfSign :

אני לא מתמצא בקטע המטמטי של העניין אבל המנוע של הביטורנט הפך להיות מיושן וצולע לעומת זה של emule . לפי המודל של ביטורנט שתיארת פה ייקח להוריד סרט באורך 700 מגה משהו כמו שלושים שנה...

הבחירה בביטורנט נובעת משתי סיבות: היא לא מקושרת בהכרח לשימושים לא חוקיים (ולראיה כמות ההפצות שמאפשרות היום הורדה בשיטה זו - מנדרייק, פדורה, סלאק ועוד...) וסיבה שניה היא שמדובר בקוד פתוח וחופשי (אני לא יודע אם eMule כזו אבל היא לא עונה על הקריטריון הראשון).

כנראה שיש סיבה טובה מאוד למה דווקא ביטורנט הפכה לחביבת מפיצי תוכנה חופשית, כך שאם מישהו יודע אז אפשר לספק מידע גם על זה...

בכל מקרה, חשבתי קצת על המקרה שכולם מתחילים להוריד בו זמנית ואפילו למקרה אחד פשוט הבעיה לא פשוטה בכלל. בגדול, הורדה מביטורנט מורכבת משני חלקים: החלק הראשון, שבו לא מנוצל רוחב הפס העולה של כל המתחברים, והחלק השני שבו יש מספיק מקטעים ייחודיים אצל כל המחוברים לרשת כך שכולם מעלים בתפוקה מקסימלית.

ברשת לא סימטרית (דהיינו המחוברים בעלי רוחב פס העלאה שונה) הבעיה הרבה יותר מסובכת כי אז ביטורנט מקצה רוחב פס להורדה לפי מה שמספקים כלפי מעלה. בהנחה שלכולם אותו רוחב פס עולה כמו שהגדרתי, בתיאוריה כולם צריכים לקבל הזנה אחידה מהזורע הראשוני.

אם נניח שיש זורע ראשוני אחד ועשר עלוקות, ורוחב הפס העולה של הזורע הוא 10KB אז כ"א מהעלוקות יקבל 1KB. בהנחה שכל מקטע הוא 1KB, הרי שאחרי שכ"א מעשר העלוקות הוריד 1KB של מקטע אחר, פתאום כל עלוקה יכולה להוריד 11KB (כאשר 1 מהזורע ו 1 מכ"א מהעלוקות האחרות).

במצב האופטימלי, כל זורע/עלוקה יעלה 10KB ובסה"כ 110KB בדוגמה שהבאתי. בחלוקה ל 10 עלוקות כל עלוקה תוכל להוריד במקסימום 11K. במצב זה, כל עלוקה תוריד את ה ISO בכ 15 שעות. אבל, יש את החלק הראשון שהוא תנאי לניצול מקסימלי. אם לא יהיו מספיק מקטעים זמינים, לא ינוצל רוחב הפס ואז לא נגיע אפילו ל 11KB.

החלק הראשון, מסבך עוד יותר את הבעיה כי נראה שצריך להיות שיווי משקל בין מספר העלוקות לגודל כל מקטע. למה? אם למשל מקטע הוא של 1K ויש 10 עלוקות, אז נדרש להמתין פרק זמן של 1הורדת 1K לפני שכל עלוקה תתחיל לתרום לשאר. לעומת זאת אם יהיו 100 עלוקות שכ"א תקבל 0.1K ברור שזמן ה Setup להפצת המקטע הראשון יגדל פי 10.

עוד רמה של סיבוך היא, נניח שכולם הורידו את המקטע הראשון מכל העלוקות האחרות, האם הזמן שעבר הספיק לכולם להוריד עוד מקטע חדש מהזורע. אם כן, אנחנו בתפוקה מקסימלית (דהיינו שלב ב) אחרת אנחנו חוזרים לנקודת האפס ועוד פעם כולם צריכים להוריד מקטע אחד שלם מהזורע כדי שאפשר יהיה להפיץ...

עכשיו תסבכו ע"י נוסחה סטטיסטית של כמה מתחברים/מתנתקים בו זמנית, רוחבי פס שונים וכו', ותראו שהבעיה בכלל לא פשוטה

Anonymous :

קרא על מצב ה superseed של הקלינט הניסיוני כאן

תודה!!! זה נראה כיוון מבטיח לשיפור היעילות בתרחיש שתיארתי, וגם מאפשר לי לחשב כמה זמן ייקח עד שלכל המעוניינים יהיה iso אם מניחים שכולם מתחברים בו זמנית בהינתן כמות המורידים והנחה שלכולם רוחב פס עולה זהה:

לפי מה שנאמר שם, זורע בודד צריך להעלות במוד הזה 105% מהקובץ לפני שהעלוקות מתחילות לתרום להזנה, מה שמרמז של 10 עלוקות עם 10K upstream ידרשו 18 שעות לפני מעבר לשלב ב' שתיארתי למעלה. מאותו רגע, רוחב הפס להורדה יהיה 11*10 בחלוקה לעשר עלוקות שזה 11K לכ"א ובסה"כ יידרשו עוד כ15 שעות לסיום שלב ב', ובסה"כ כ 33 שעות עד שלכל ה 10 יש iso שלם.

במקרה של זורע בודד ועלוקה אחת, יידרש פרק זמן של 100% מהקובץ בלבד ז"א קצת יותר מ 16 שעות עד שלעלוקה יהיה iso מלא.

אם יהיה זורע אחד ו 100 עלוקות, אז שלב א' עדיין ייקח 18 שעות (זהה ל 10 עלוקות) ורוחב הפס להורדה לכל עלוקה יהיה 10*101 חלקי 100 או קרוב ל 10K ובסה"כ 16.5 שעות להשלמת ההורדה שזה 34.5 שעות.