הקצאת כתובות

סיכום

מבוא:

יש יחסי תלות בין הממשקים, ומכיוון שהגדרות שונות של מכשירים עשויות לדרוש כתובות TCP/IP והקצאת מסלולים שונות, היה חשוב שהלוגיקה לשליטה בכתובת IP ובהקצאת נתיבים תאחד למודול אחד. WARM נועד להוסיף ולהסיר כתובות TCP/IP ו'ניתובים אל ממשקי IP הקשורים ל-Weave' כאשר הממשקים האלה עוברים ממצב פעיל<->לא פעיל.

WARM מיועד להיות מוגדר בזמן ההידור באמצעות WarmProjectConfig.h ו-WarmConfig.h. רכיב HeatProjectConfig.h חייב לשקף במדויק את התכונות הנתמכות של המכשיר שבו יתבצע WARM.

WARM הוא מודול נייד שמגביל את התלות שלו באופן שבו מוגדרים מחסנית TCP/IP וממשק Thread Interface. למטרה זו, WARM מסתמך על קבוצת API של פלטפורמה שחובה להטמיע על ידי משלב הפלטפורמה. בנוסף, 'משלב הפלטפורמה' אחראי לביצוע הקריאות השונות של nl::Warm API מנקודות ביצוע מתאימות בבסיס הקוד של הפלטפורמה.

תורת הפעולה:

בסיס קוד הפלטפורמה יקרא nl::Warm API כדי להודיע על שינוי מצב של תכונות קשורות, כגון ממשק ה-Wi-Fi וממשק Thread. קריאה לכל אחת מ- nl::Warm API עשויה לגרום להפעלה של WARM אל Platform::RequestInvokeActions(). יש להטמיע את Platform::RequestInvokeActions() כדי לבצע את הפעולות הדרושות שיקראו ל-Warm::InvokeActions(). תהליך זה במבט ראשון עשוי להיראות עקיף שלא לצורך. למה לא לבצע WARM להתקשר ישירות ל-InvokeActions? התשובה לשאלה היא לאפשר לכל משימה במערכת לריבוי משימות להפעיל את nl::Warm State Change API’s ולספק מנגנון כך שרק משימה ספציפית תפעיל את הפלטפורמה: API של הפלטפורמה: API. אחרי שהביא בחשבון את דרישות הפלטפורמה, יכול לשלב הפלטפורמה:

כשהפונקציה Warm::InvokeActions() נקראת WARM תבחן את מצב המערכת הנוכחי ותבצע קריאות ל-Platform: API הנדרשות כדי להתאים את הכתובת ואת מצב הניתוב למצב המערכת והתצורה. הקריאות האלה מתבצעות בסדר מוגדר מראש, ואם פעולת kPlatformResultInProgress של ממשקי ה-API האלה תוחזר, הביצוע של הרשימה המוזמןת ישעה ויסתיים. בנוסף, כאשר אחד מממשקי ה-API האלה מחזיר kPlatformResultsInProgress, מתפרשים שהפעולה תושלם באופן אסינכרוני ושהלוגיקה של WARM צריכה להמתין לסיום הפעולה. לאחר השלמת הפעולה, קוד הפלטפורמה צריך לקרוא ל-Warm::ReportActionComplete(), ולהעביר אותו כתוצאה מ-kPlatformResultsSuccess או ל-kPlatformResultsFailure. לאחר קבלת הקריאה הזו, הלוגיקה של WARM תפעיל שוב את Platform::RequestInvokeActions() כדי להתחיל מחדש את הביצוע של רשימת הפעולות המוזמנת.

כך האפשרות WARM לא מחייבת משימה משלה, אלא יכולה להסתמך על משימה אחרת כדי להפעיל את האפשרות 'חמימות' לפי הצורך. בנוסף, כל משימה יכולה להפעיל ממשק API אחד או יותר לשינוי מצב המערכת, וכך לפשט את השילוב.