משלוח קבצי ענק

[yonigold]

משלוח קבצי ענק

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

 

[אורן עיני]

Nil ref error

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

 

[pun dog]

שאלה שקשורה לנושא

במשלוח/קבלת soap ב ws, ניתן לכתוב soap extension ולהשתמש באפשרויות כיווץ שונות שמופעלות על קובץ ה soap שעובר ברשת. מאחר ומדובר בקובץ טקסט, אז היעילות יכולה להוריד את גודל הקובץ עד כ 80% .. מה מונע מלהשתמש באותה צורה ולחסוך ברוחב פס במקרה הזה?

 

[jonyBgood]

הרעיון שלך מענין, אבל לא מתאים כאן

הרעיון שלך מענין, אבל לא מתאים כאן, הוא מדבר על קבצים של 2GB ... קשה לי להבין איזה אמינות אפשר לספק בהעברת הקבצים האלה דרך ה IIS - WebServices הוא צריך כאן מוצר אמין שיודע לשמור state ובמקרה של נפילת תקשורת ממשיך להוריד מהמקום בו הופסק.

 

[yonigold]

תגובה לכולם

לגבי הכיווץ: מדובר בקבצים בינאריים. אין כמעט מה לכווץ. בגדול אנחנו משתמשים בMTOM לאופטימיזציה (WSE3) אבל עדיין יש פה קובץ של 2 ג'יגה... אורן, מה מייחד את הטכנולוגיה הזאת ונותן לה יתרון על FTP?

 

[איפכא מיoתברא]

אין קשר בין בינארי לבין כיווץ

כיווץ טוב או לא טוב נובע מאלגוריתם הכיווץ ומאופי המידע אותו יש לכווץ. לדוגמא: קובץ בינארי שנראה כך: 000100010001000100010001000100010001 מאד קל לכווץ

 

[EdotK]

אוי נו באמת...

קובץ בינארי זה קובץ שמממש את כל הסיביות בבייט לשמירת מידע, ולפיכך הרבה יותר יעיל מלכתחילה מאשר קובץ טקסט שמתמש סה"כ ב5-6 סיביות מתוך 8 בבייט שלם, או אפילו מתוך 16 אם יש שימוש בUnicode. קובץ טקסט ניתן לכווץ בקלות ב80%. קובץ בינארי סטנדרטי קשה לכווץ ביותר מ40%.

 

[איפכא מיoתברא]

אוי נו באמת....

סתם זרקת מספרים? על סמך עקרונות היוריסטיים? הדרך היחידה לבדוק את יכולת הדחיסה היא באמצעות בדיקת רמת האנתרופיה. מטרתם היחידה של אלגוריתמי דחיסה (ולא משנה אם זה דחיסה של תמונה בwavelets, דחיסת קול בADPCM או דחיסה באופן כללי כמו אלגוריתם ZIP) הינם לקחת ייצוג מסויים של מידע ולתת ייצוג אחר שתופס פחות מקום פיזי. מכיוון שאתם מדברים על דחיסה מסוג loseless (בהנחה שהקבצים הענקיים עליהם מדובר אינם קבצי תמונה או וידאו) הרי שמרבית האלגוריתמים לדחיסה כזאת כלל אינם מתייחסים לסוג הקובץ עצמו אלא רק למידע הבינארי. ברור שאם מדובר בקובץ טקסט פשוט בו ישנם אזורים רבים המרופדים באפסים יהיה קל יחסית לדחוס אבל ממש לא הייתי מניח שזה המצב. לגבי ההנחה שהעלה המגיב השני - 1. היא שגויה. קח לדוגמא קובץ PSD של פוטושופ. קובץ בזבזני לחלוטין ללא דחיסה. ניתן לדחוס אותו לעיתים ביותר מ90 אחוז. 2. היא לא דווקא רלוונטית לתוכנות שמייצרות קבצים בגודל כזה. קובץ כזה מריח לי כמו מערכות MF ישנות, מערכות פיננסיות עתיקות או מערכות מודיעין - מערכות כאלה מייצרות פעמים רבות קבצי ענק בעלי מבנים שונים ומשונים שהוגדרו לצרכי הארגון. אין שום דרך להניח משהו על רמת האנתרופיה שלהם. ואם זה ממש מעניין אותכם יש יופי של קורס באונ' ת"א ובמכללה האקדמית של ת"א יפו בנושא דחיסה כולל ביצוע פרוייקטים מעשיים.

 

[EdotK]

נו באמת

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

 

[איפכא מיoתברא]

OK אין לי כוונה להתווכח

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

 

[EdotK]

זה טעות הקלדה

אמור להיות "שקובץ טקסט מלכתחילה ניתן לכיווץ הרבה יותר מקובץ בינארי".

 

[איפכא מיoתברא]

אני יודע שלכך התכוונת

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

 

[EdotK]

בטח בבי"ס היית מהתלמידים

המעצבנים האלו שתמיד ניסו להתחכם

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

 

[IdleThought]

../images/Emo132.gifלא לרדת על חנונים בבקשה...

 

[איפכא מיoתברא]

קובץ טקסט של סטודנט למדעי המחשב?

כי שם באמת תמיד יש רק 256 characters בעולם המציאות סיכוי יותר מסביר שהקובץ לא יכיל רק 256 סוגי תוים אלא הרבה יותר - בקידודים שונים כמו UTF-8 למשל... בעולם המציאות תמצא גם תוכנות כמו ספוטניק ש(כמעט) כל מה שהן עושות זה להעביר קבצי PSD ענקיים בינאריים ובלתי מכווצים בעליל בין משרדי פרסום לבתי דפוס וכד'... לגבי אנתרופיה - זה לא הופך למאד מעניין אבל זה עדיין הנקודה הבסיסית העקרונית מאחורי כל נושא הדחיסה בין אם תאהב את זה ובין אם לא. ולעניין הבית ספר - בהחלט הייתי מציק ומתחכם, אבל רוב הזמן הייתי בדיזינגוף סנטר ובים...

 

[IdleThought]

אם קלעתי לכוונתנו של EDOTK

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

 

[pun dog]

../images/Emo41.gif למה להסתבך?!

http://squeezechart.meine-hp.net/index.htm

 

[IdleThought]

הממפ

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

 

[pun dog]

בתכלס'..

אפשר לראות בטבלה הראשית את היחס בין כיווץ מידע טקסט, לעומת סוגים שונים של מידע "בינארי",

 

[pun dog]

בתכלס'..

אפשר לראות בטבלה הראשית את היחס בין כיווץ מידע טקסט, לעומת סוגים שונים של מידע "בינארי",