Wiki he il

Raknetify2 · עברית (ישראל)

שפה

• ה home
• התקנה
• Velocity ו-BungeeCord
• הגדרות פיירוול ורוטר
• תאימות
• מצב מסודר
• העברות אוטומטיות
• העברה של UDP ופרוטוקול PROXY
• Simple Voice Chat
• טיפול בבעיות
• שילוב מודים
• פרוקסיות UDP

רב-משתתפים

חיבורי רשת באמצעות RakNet ללקוחות ולשרתים של Minecraft.

הורד · GitHub

Minecraft	Raknetify2	לקוח / שרת
Fabric	mods/raknetify2-fabric-*.jar	לקוח / שרת
Forge	mods/raknetify2-forge-*.jar	לקוח / שרת
NeoForge	mods/raknetify2-neoforge-*.jar	לקוח / שרת
Spigot / Paper	plugins/raknetify2-spigot-*.jar	שרת
Velocity	plugins/raknetify2-velocity-*.jar	Velocity
BungeeCord	plugins/raknetify2-bungee-*.jar	BungeeCord

הוסף שרת

1. רב-משתתפים

2. הוסף שרת

3. כתובת השרת

   	כתובת השרת
   RakNet · UDP	raknet;play.example.com:25565
   TCP	play.example.com:25565

4. בצע

5. הצטרף לשרת

F3 · Raknetify2

	F3
RakNet · UDP	פעיל · MTU 1400
TCP	לא פעיל

Velocity / BungeeCord

1. לקוח · Raknetify2 → UDP → Velocity / BungeeCord · Raknetify2
2. Velocity / BungeeCord → TCP → שרת

	מספר פורט · UDP	Java
Fabric / Forge / NeoForge	1–65534	-Draknetify.fabric.portOverride=25570
Spigot / Paper ≥ 0.1.0-beta.1.431	1–65535	-Draknetify.spigot.portOverride=25570
Velocity	1–65534	-Draknetify.velocity.portOverride=25570
BungeeCord	1–65534	-Draknetify.bungee.portOverride=25570

אזל זמן החיבור

כתובת השרת	UDP
raknet;play.example.com:25580	play.example.com:25580 → NAT → 192.0.2.10:25570
שרת · 192.0.2.10	25570/udp

config/raknetify2-compatibility.json

שרת / Velocity / BungeeCord

	JSON
① ② ③	{"mode":"ordered"}
① ∥ ② ∥ ③	{"mode":"multichannel"}

Simple Voice Chat

שרת	Raknetify2 · UDP 25565	Simple Voice Chat
Fabric / Forge / NeoForge	config/raknetify2-voicechat.json · {"enabled":true}	config/voicechat/voicechat-server.properties · port=-1
Spigot / Paper	config/raknetify2-voicechat.json · {"enabled":true}	plugins/voicechat/voicechat-server.properties · port=-1

Simple Voice Chat · Velocity / BungeeCord

PROXY protocol v2 · UDP

כתובת השרת	trustedProxies	RakNet
192.0.2.10 · PROXY v2 / UDP	["192.0.2.10"]	✓
192.0.2.11 · PROXY v2 / UDP	["192.0.2.10"]	✗
לקוח → RakNet / UDP	["192.0.2.10"]	✗

config/raknetify2-proxy-protocol.json

{"trustedProxies":["192.0.2.10"]}

Minecraft ≥ 1.20.5 · /transfer

1. שרת A · Fabric / Forge / NeoForge · config/raknetify2-transfers.json

   {"destinations":[{"host":"play.example.com","tcpPort":25565,"udpPort":25570}]}

2. שרת B · play.example.com · server.properties → accepts-transfers=true

3. שרת A · /transfer play.example.com 25565 Alex → לקוח (Alex) → RakNet · play.example.com:25570

PacketOrdering

	Minecraft
ui	אפשרויות
entity	שלד
world_interaction	תיק חפצים
effects	חלקיקים
chunk	בלוקים

PacketOrdering.java

גרסת משחק לא תומכת!

• Fabric · compatibility.json · gameVersions / runtimes / depends
• Forge / NeoForge / Spigot / Paper · GitHub Releases

דווח על תקלות

ה home

Raknetify2

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

Raknetify2 הוא פיצול של Raknetify, ש־ishland פיתח במקור. הפיצול מתוחזק באופן עצמאי, מוסיף תמיכה בגרסאות חדשות יותר של Minecraft וממשיך לתחזק את קוד התקשורת, את השילוב עם הפלטפורמות ואת בדיקות התאימות.

התחלו

1. בדקו את התאמה של Minecraft ומודים.
2. בחרו את ההורדה ותרמו אותה.
3. חברו לכתובת כמו raknet;play.example.com.

הנחיות לשרת

• Velocity ו-BungeeCord
• הגדרות פיירוול ורוטר
• העברות אוטומטיות
• העברת UDP ופרוטוקול PROXY
• שיתוף פורט UDP עם Simple Voice Chat
• תיקונים ודיווחי פגמים

מפתחים יכולים להשתמש עם גרם הפעלה של הפרוטוקולים (packet ordering interface) כדי לציין את ההתלות בין נתונים מותאמים לבין תעבורת Minecraft.

קישורים לפרויקטים

• הדפסה
• קוד מקור
• מעקב פתרונות
• בנייה ובדיקות התאמה

Raknetify2 משתמש בהתקן הרישיון MIT ושומר על ההערות של זכויות היוצרים המקוריות. הביצועים שלו ברשת מבוססים על Raknetify ו- netty-raknet.

התקנה

הורידו גרסה מחדש מה-GitHub Releases. בדקו את גרסת Minecraft ודרישות ההתקנה של אותה גרסה לפני ההתקנה.

במקום שבו אתם מתקינים	קובץ	הפורמט
קלטן או שרתן של Fabric	raknetify2-fabric-*.jar	mods
Forge client או Forge server	raknetify2-forge-*.jar	mods
קלטן או שרת NeoForge	raknetify2-neoforge-*.jar	mods
שרת Spigot או שרת Paper	raknetify2-spigot-*.jar	plugins
Velocity Proxy	raknetify2-velocity-*.jar	plugins
פרוקסי BungeeCord	raknetify2-bungee-*.jar	plugins

סגור את הלקוח או עצרו את השרת לפני החלפת JAR שלו. הוציאו את JAR המקורי של Raknetify ואת JAR של Raknetify2 יותר ישן מהאינסטלציה אותה, לפני הוספת הקובץ החדש.

הקבצים של הלקוח שייכים למודול המאפשר את הפעלת המשחק Minecraft או לקבוצת מודים שאתם מפעילים. הקבצים של השרת והפרוקסי שייכים להתקנה של השרת או הפרוקסי. יש ליצור את הקובץ המתאים אם המארח שלכם עדיין לא יצר אותו.

חיבורים ישירים לשרת

1. התקינו את המוד של הלקוח ללודר שלכם.
2. התקינו את המוד של השרת המתאים, או את הפלגול Spigot/Paper על שרת שתואם.
3. עקבו אחר הגדרות פיירוול ורוטר כדי לאפשר קישורים UDP למארח.
4. הפעלו מחדש את הלקוח ואת הסרver.
5. הוספו כתובת שרת כמו raknet;play.example.com או raknet;play.example.com:25565.

כתובות ללא הקידומת raknet; משתמשות ב-TCP.

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

Velocity ו-BungeeCord

התקינו את הפלגרי המתאים ואת המוד של הלקוח. עקבו אחר ההוראות של Velocity ו-BungeeCord לגבי ההגדרות של המאזין, העברת האימיילים מהצד האחורי, הגבלות על הגישה, וכתובת שעל השחקנים להשתמש בה.

פורט קליטה נפרד של UDP

לשרת Minecraft ישיר, קבלו את הארגומנטים Java המתאימים למטה. מפעילי פרוקסי צריכים להשתמש בהגדרות הקלט של Velocity וBungeeCord.

פלטפורמה	ארגומנטים של Java	שערים מקובלים
שרתי Fabric, Forge או NeoForge	-Draknetify.fabric.portOverride=25570	1 עד 65534
שרת Spigot או שרת Paper	-Draknetify.spigot.portOverride=25570	1 עד 65535

Forge ו-NeoForge משתמשים בקוד המאזין המשותף, לכן שמות הנכסים שלהם כוללים גם fabric. החליפו 25570 בפתח UDP הרצוי.

Spigot / Paper ≥ 0.1.0-beta.1.431

הוסף הארגומנט לפני -jar במתווה של Java, או בתיבת הארגומנטים של JVM של ההומן שלך. התחיל מחדש את השרת והרשם לתקשורת UDP בפורט המתאים. אם הפורט הציבורי הוא גם 25570, חבר עם raknet;play.example.com:25570. אם רוטר מתרגם את הפורט, השתמש בפורט הציבורי שלו במקום. פורט TCP יישאר בערכו הקיים.

על מערכת Spigot/Paper, המקשיב UDP שומר את כתובת החיבור המקומית של המקשיב TCP של Minecraft. פורט UDP לא תקין או תפוס מסווג את RakNet מלתחילה. בדקו את לוגי ההתחלת הלוגי לגבי כתובת ופורט UDP. מחקו את הארגומנט ותחילו שוב כדי לחזור למספר הפורט של המקשיב TCP.

רוטר או פרוקסי UDP יכולים גם לספק פורט UDP ציבורי שונה ולהעביר אותו אל המאזין הקיים, מבלי לשנות את ארגומנטי ה-Java של השרת.

בניית פיתוח

פתחו את המשימה main המוצלחת ב-GitHub Actions והפקידו את הארכיון Artifacts שלה. GitHub דורש חשבון כדי להפקיד את המוצרים של שגרורות. השתמשו בטבלת ההתקנה שלעיל כדי לבחור JAR מארכיון זה.

Velocity ו-BungeeCord

Velocity ו-BungeeCord ממוקמים בין השחקנים לבין שרתי Minecraft האחוריים. יש ליישם Raknetify2 על הפרוקסי ועל כל הלקוחות שיתקשרו דרך RakNet.

Raknetify2 client --UDP--> Velocity או BungeeCord --TCP--> backend server

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

התקינו את הפרוטקטור פלגינט.

1. הבטיחו שקישורים TCP רגילים דרך הפרוקסי שלכם עובדים, כולל אימות והחלפה בין שרתי הבאקס.
2. עצור את הפרוקסי והורידו את הפלגינג המתאים מכתובת GitHub Releases.
3. הציבו את raknetify2-velocity-*-all.jar או raknetify2-bungee-*-all.jar בפלטפורמת הפרוקסי, בתיקיית plugins. הורידו כל פרוטוקול Raknetify או Raknetify2 ישן מתיקייה זו.
4. התקינו את המוד של Raknetify2 המתאים באמצעות ההנחיות להתקנה הנה.
5. בדקו את ההגדרות של המאזין למטה, הפעילו מחדש את הפרוקסי, ובדקו את הלוג שלו לגבי שגיאות במאזין RakNet.
6. אפשרו תעבורה ציבורית בפורט UDP לפרוקסי, וצמצמו פורטי המשחק בחלק האחורי כפי שתואר ב-הגדרות שרת וחומרה.

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

Velocity

המתאם bind בקובץ velocity.toml בחר את כתובת ההאזנה של Minecraft ומשרוך TCP של Velocity. Raknetify2 משתמש בדרך כלל באותו מספר משרוך ל-TCP עבור UDP. הרשומות [servers] מזהות את שרתי ה-backend. יש לשמור שרשומות אלו מצביעות על כתובות TCP של שרתי ה-backend. ראו את המפרט של Velocity.

כדי להשתמש לכתוב דף פרוטוקול נפרד של UDP, הוסיפו ארגומנט זה ל-JVM לפני -jar במפתח ההתחלתי של Velocity:

-Draknetify.velocity.portOverride=25570

תחליפו את 25570 בפתח שאתם בוחרים. כך ישתנה פתח UDP של RakNet, תוך שמירה על פתח TCP וכתובות הליבה של Velocity. יש לזרוק מחדש את Velocity לאחר שינוי הארגומנט.

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

BungeeCord

בקובץ config.yml של BungeeCord, ערך host שבכל פיסת listeners מזהה את כתובת ההאזנה של Minecraft ואת שער ה-TCP. Raknetify2 מנוסה בדרך כלל להוסיף שער UDP באותו מספר שער. פיסות servers מכילות כתובות TCP של ה-backend. ההגדרות האלו מתוארות בהנחיות ההגדרה של BungeeCord (BungeeCord Configuration Guide).

לכתובורת UDP נפרדת, הוסיפו את הארגומנט הבא לפני -jar בפקודת הפתיחה של BungeeCord:

-Draknetify.bungee.portOverride=25570

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

יש להשאיר את אימות החשבונות פעיל בפרוקסי. לשרתי Spigot, המדריך של BungeeCord להעברת כתובות IP מורה להגדיר ip_forward: true בפרוקסי ו־settings.bungeecord: true בשרת שמאחוריו. ההעברה לבדה אינה מונעת חיבור ישיר לשרת. הגבילו את הגישה לפי הוראות חומת האש.

בחרו את הכתובת שבה משתמשים השחקנים.

שני סוגי העריכות של הפרוקסי מקבלים פתחים מ1 עד 65534. ערכים לא תקינים נדחים, ולכן יש לבדוק את פתח ה-UDP המתחבר בפרוטוקול ההתחלתי. מחקו את הארגומנט ותחילו שוב כדי לחזור למספר הפתח של המאזין של Minecraft.

השחקנים מחוברים לשם המחשב הציבורי של הפרוקסי ולתוף UDP שלו, למשל raknet;play.example.com:25570. כאשר רוטר מתרגם תיבות תקן, יש להשתמש בתוף UDP הציבורי שלו בכתובת הלקוח. כתובות שאין בהן הקידומת raknet; ימשיכו להשתמש במרואשר של הפרוקסי בזמן TCP.

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

שיחת קול והעברה נוספת של UDP

ב־Velocity וב־BungeeCord יש ל־Simple Voice Chat תוסף פרוקסי ויציאת UDP משלו. להגדרה הזאת יש לפעול לפי מדריך הפרוקסי של Voice Chat.

אם יש מעבורת UDP נפרד שממוקמת לפני הפרוקסי שלך ל-Minecraft וששולח כותרות פרוטוקול PROXY v2, יש להגדיר את Raknetify2 באמצעות העברת UDP ופרוטוקול PROXY. התקנת Velocity או BungeeCord לבדה אינה דורשת הגדרה כזו.

בדקו את הקישוריות.

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

• אם TCP עובר דרך הפרוקסי אך RakNet עוצר, יש לבדוק את המאזין של UDP של הפרוקסי, השער הציבורי, דרכי ה-IPv4 וה-IPv6, וחוקי המחסום.
• אם שני המתקנים נכשלים כאשר הפרוקסי מחובר לבקרת, יש לבדוק את כתובת ה-TCP של הבקרת, חוקי הגישה וההגדרות של העברת השחקנים.
• אם הפרוקסי מדווח על שער UDP תפוס, בדקו האם יש תהליך Query, Geyser, פרוקסי קול, או תהליך אחר המחובר לשער זה.

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

הגדרות פיירוול ורוטר

המדריך הזה מיועד לבעלי שרתים. Raknetify2 זקוק לנתיב UDP תקין אל השרת או הפרוקסי המקבל קישורים RakNet. ההגדרה המקובלת משתמשת במספר השערה זהה לזה של מקלט ה-TCP של Minecraft.

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

בחרו את המקום והשער.

שרת ישיר

שלחו תעבורה UDP ציבורית למחשב שמשמש כשרת Minecraft באמצעות Raknetify2. הפורט היעד הוא מערכת ההאזנה של RakNet UDP של השרת. יש לאפשר את הפורט הזה בפרצוף המארז של המחשב. יש להשאיר את מסלול ה-TCP הקיים לחיבורים רגילים של Minecraft.

לדוגמה, אם Raknetify2 שומע על UDP 25570, יש להעביר את השער הציבורי של UDP לכתובת המקומית של השרת על שער 25570. שער ה-TCP של השרת יכול להישאר על 25565. ראו הגדרות המאזין של השרת הישיר כדי לבחור שער UDP אחר.

Velocity או BungeeCord

יש להפנות תעבורת UDP ציבורית למחשב שמריץ את Velocity או את BungeeCord עם תוסף הפרוקסי של Raknetify2. יעד ההפניה הוא הכתובת והיציאה שבהן הפרוקסי מקבל חיבורי RakNet על גבי UDP. יש לשמור על נתיב ה־TCP הציבורי הקיים של הפרוקסי לחיבורי Minecraft רגילים.

הפרוקסי מחובר לשרתי Minecraft האחוריים דרך TCP. הוספת Raknetify2 לפרוקסי אינה דורשת פתיחת שערי UDP של המשחק האחורי לצורך קבלת משתמשים.

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

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

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

מספרי הפרוטקציה הציבוריים והמקומיים

התחנה הציבורית והתחנה של המאזין יכולות להיות שונות כאשר הרוטרה מנתב ביניהן.

הגדרות	מספר שירות לשימוש
כתובת הלקוח-שרת	שער UDP ציבורי
חוק העברת ההודעות של הסרוור, תחנת החוץ	שער UDP ציבורי
חוק העברת הרשת של הרוטר – התחנה הפנימית	שער UDP של מקלט RakNet
הספק הפרנזה המקומי של המארח	שער UDP של מקלט RakNet

העברת שערי פורט IPv4

לאירוח מאחורי רוטרי IPv4:

1. מצאו את הכתובת IPv4 המקומית של המחשב שמקבל קישורות RakNet. השתמשו בהקצאה DHCP או בכתובת סטטית מתאימה, כך שחוק ההפניה ימשיך לכוון על אותו מחשב.
2. הוספו חוק העברה של UDP לתוך המספר הפומבי ששחקנים ישתמשו בו.
3. הגדירו את יעד החוק לכתובת המקומית של המחשב ההוא ולתוף UDP של מקש השמע של RakNet.
4. אפשרו לתקשורת UDP פנימה בכתובת הפוקסל של המאזין, במחסום החומרה של המחשב.

לדוגמה, שרת שמקשיב לתעלה UDP 25565 יכול להשתמש בחוק עם תעלה ציבורית 25565, כתובת יעד 192.168.1.100 ותעלה יעד 25565. החליפו את הכתובת הדוגמה בכתובת המקומית האמיתית של השרת שלכם.

יש להשאיר את חוקי TCP הקיימים לחיבורים רגילים ב-Minecraft. חוק העברה ב-TCP לבדו אינו יכול להעביר UDP.

כאשר העברה עדיין לא עובדת

בדקו האם רשת נוספת או ספק האינטרנט שלכם מבצעת NAT לפני שהדטה מגיעה לרשת שלכם. כאשר יש שני רשתות, יש לבצע את הפינייה בשתיהן. אם ספק האינטרנט שלכם משתמש ב-NAT ברמה של חברת תקשורת, שאלו האם הם יכולים לספק כתובת IPv4 ציבורית או להשתמש בשירות אירוח או בצינור שתומך ב-UDP פנימי. חוקי הפינייה של הרשת שלכם אינם יכולים להגדיר את NAT של ספק האינטרנט. ראו הנחיות TP-Link לפינייה של פורטים לגבי דרישות הכתובת הציבורית של WAN.

חוקי מגן האש של IPv6

אפשרו את השימוש בדף ה-UDP הנבחר דרך חומה ההגנה של IPv6 של הרשת וכן דרך חומה ההגנה של המחשב. ציינו את כתובת ה-U6 של המחשב שמקבל קישורים RakNet.

בדקו שהכתובת IPv6 של שם המחשב מצביעה על המחשב הזה. אם הכתובת IPv6 שלו משתנה, אפשר לעדכן את רשומות ה-DNS וכל חוקי המחסום האזורי.

שם המחשב שמפרסם גם את הכתובות IPv4 וגם את הכתובות IPv6 צריך להיות מכיל את הנתיבים המתאימים לכל כתובת שמפרסמת. יש לבדוק את שני סוגי החוקים כאשר שחקן אחד יכול להתחבר ואילו שחקן אחר לא.

אם העברת IPv4 משנה את מספר הפורט, ודאו שהפורט שמשתמשים בו יגיע גם למקשיב IPv6. תרגום של פורט IPv4 אינו מכוון את מסלול הIPv6.

ספקי אחסון ומנהרות תקשורת

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

אם פרוקסי UDP נוסף מעביר את כתובות המשתמשים באמצעות פרוטוקול PROXY v2, יש לעקוב אחר ניהול הפרוקסי של UDP ופרוטוקול PROXY ולהגביל את הגישה לקולמן של UDP למפרוקסי האמין.

בדקו את הקישוריות.

חברה מחוץ לרשת המקומית של השרת באמצעות קלטן Raknetify2 מעודכן, באמצעות כתובת כמו raknet;play.example.com:25565. יש להשתמש לכך לפתוח את שער ה-UDP הציבורי.

שתמשו בחיבור אמיתי של RakNet כדי לבדוק את המסלול. סריקת UDP שאינה מקבלת תגובה יכולה לדווח תוצאה לא חד-משמעית, מכיוון ששירות פעיל עשוי לדלל בדיקה לא מוכרת. המסמך של Nmap על סריקת UDP מסביר את התנהגות זו.

קישור TCP מוצלח אישר רק את מסלול ה-TCP. אם RakNet עוצר, בדקו את המאזין, יעד ההעברה, שער ה-UDP וחוקי המחסום באמצעות ההנחיות לטיפול בבעיות הנוסחה.

תאימות

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

גרסאות Minecraft ו-Java

לגבי Fabric, הורידו את compatibility.json מהאותו פרויקט כמו ה-JAR. בדקו את גרסת Minecraft שלכם בקובץ gameVersions, ולאחר מכן בדקו את הפרטים הרלוונטיים בקובץ runtimes לגבי הדרישות של depends. קובץ JSON זה הוא מסמך רשום, ולכן אין צורך להכניס אותו לקבוצה mods.

לגבי Forge, NeoForge ו-Spigot/Paper, יש לבדוק את דרישות הגרסה שהצהיבה המוצר ופרסום ההורדה שלו מציינים. תמיכה בלקסר אחד אינה מבטיחה תמיכה בלקסר אחר.

הדרישה של Java שהגדירה Raknetify2 היא הדרישה המינימלית. Minecraft או המארח עשויים לדרוש ביצוע תוכנית בגרסה עדכנית יותר. בחרו גרסה של Java שעונה על כל שלוש הדרישות.

גרסאות של קלient ושרת

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

Raknetify2 מכיל את פרוטוקול המשחק הקיים של Minecraft. חיבור בין גרסאות שונות של Minecraft דורשה הרכבה של תרגום פרוטוקול הולם.

מודים אחרים

שגרת העבודה של הבנייה (build workflow) כוללת בדיקות התאמה שכוללות את Polymer, Krypton, PacketFixer ו-Fast IP Ping. בדיקות אלו עוסקות בווריאנטים ושילובים שנבחרו על ידי שגרת העבודה. יש לבדוק את תוצאות הבנייה של השקה הרלוונטית כאשר חוקרים שילוב מסוים.

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

מצב מסודר

מצב מסודר

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

הפעלת מצב מסודר

1. התקינו את עותק Raknetify2 שמאפשר את שיטת הארגון המסודר במתקן השרת או הפרוקסי שמקבל קישורות RakNet, וכן בכל לקוח RakNet.

2. יצרו את הקובץ config/raknetify2-compatibility.json בדרך ההתקנה של השרת או הפרוקסי. יצרו גם את דף הקובץ config אם הוא עדיין לא קיים.

3. הוסיפו את הטקסט הבא:

   {"mode": "ordered"}

4. הפעלו מחדש את השרת או את הפרוקסי.

הלקוחות עוקבים אוטומטית אחר ההגדרות של השרת. השחקנים אינם צריכים ליצור קובץ הגדרות או לשנות את כתובת השרת RakNet שלהם.

כל חבילות המסר ב-Minecraft משתמשות בצוהר אחד אמין ומאורגן בכל כיוון, כולל גבולות החבילות ומעברים בין עולמות.

הגדרות פרוקסי

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

הפוליסה חלה על כל מפסקי ה-backend. בפורמט מסודר, הפרוקסי מעביר את בקשות ה-keepalive של ה-backend ללקוח האמיתי, במקום לענות עליהן מקומית.

בדיקת ההגדרות

בקישורת RakNet הראשונה, הקונסולה מדווחת:

Raknetify2 compatibility: ordered (updated clients required, genuine acknowledgements)

בתהליך ההתאמה המוצלחת, גם נרשם ordered compatibility negotiated, ולאחר מכן כתובת היריב.

החזיקו בפעולה של בדיקות אנטי-cheat פעילות ובדקו את ההגדרות שלכם.

קליינדים ישנים יותר

על לקוחות RakNet שאינם תומכים במצב מסודר, לא לנסות לחברים לשרת שדורש את זה. יש לעדכן את Raknetify2 בלקוחות אלו, או להשתמש בכתובת TCP ובשעון של השרת או הפרוקסי ללא הקידומת raknet;.

חזרה למצב רב-ערוצי

שנו את הקובץ ל:

{"mode": "multichannel"}

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

בעיות בקונפיגורציה

הקובץ חייב להכיל בדיוק אפשרות אחת בשם mode, כאשר הערך שלה הוא או "ordered" או "multichannel". הערכים הללו רגישים לכתיב.

הגדרות לא תקינות או בלתי קריאות גורמות לדחיית חיבורים RakNet. תקנו את הקובץ ותחילו שוב את התהליך.

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

העברות אוטומטיות

שרתי Fabric, Forge ו-NeoForge יכולים לבחור את RakNet בעת העברת לקוח מספיק יעיל למקום המתאים. זה משתמשת תמיכה העברה מקורית של Minecraft, שהוכנסה ל-Java Edition 1.20.5. יש לוודא ששנת ההפצה Raknetify2 שלך תומכת בווריאנט ובלודר של Minecraft בשני הצדדים.

התקינו את Raknetify2 בלוח המשלוח ובלוח הקליינד. היעד חייב לספק מקלט RakNet תואם ולקבל העברות Minecraft שמגיעות.

ההגדרה הזו חלה על העברות שנשלחות על ידי שלושת מערכות ההטמעה הנ”ל. הפרקלטים Spigot/Paper, Velocity ו-BungeeCord אינם קוראים את קובץ העברות זה.

הגדרת השרת השולח

יצרו את הקובץ config/raknetify2-transfers.json בדירקטוריית השרת המעביר.

{
  "destinations": [
    {
      "host": "play.example.com",
      "tcpPort": 25565,
      "udpPort": 25570
    }
  ]
}

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

שדה	משמעות
host	שם המחשב של היעד או כתובת IP, ללא קידומת תובלה או פורט.
tcpPort	שער היעד בבקשת העברה המקורית
udpPort	הלקוח המעביר צריך ליצור קשר עם שער ה-RakNet הציבורי.

מספרי התיבות TCP ו-UDP יכולים להיות שווים. אם רשת מטרתת מטבילה את תיבות UDP, יש להשתמש בתיבה הציבורית שמופיעה בקובץ זה. רשמו את התיבות כמספרים בפורמט JSON.

שלוח העברות למשתמש הישיר ולתוף TCP של המקום היעד. Raknetify2 בודק האם הלקוח מציג תמיכה בעברות אוטומטיות. עבור לקוח בעל יכולות ומקום יעד מתאים, הוא בוחר את תוף UDP המתקבל. ללקוחות אחרים ולמקומות יעד לא מתאימים, נשמר כתובת העברה המקורית.

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

הגדרת יעדים

ליעד שמשתמש ב-server.properties של Minecraft, יש להגדיר את accepts-transfers=true ולתחילת שובה. יעד הפרוקסי עשוי להיות בעל ההגדרות שלו משלו. Minecraft מפריע בדרך כלל להעברות קוראים, גם כאשר הצטרפות ישירה רגילה עובדת.

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

בדקו את מסלולי ה-IPv4 ו-IPv6 של היעד, כאשר שם המחשב שלו מפרסם שני סוגי כתובות. בדקו קודם את הקישוריות הישירה הרגילה של RakNet עם היעד, לפני בדיקת התנהגות העברת הנתונים האוטומטית.

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

שגיאות בקונפיגורציה ושלילתה

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

כדי לבטל את בחירה אוטומטית, יש למחוק את קובץ ההגדרות או להשתמש ב{"destinations": []}, ולאחר מכן להתחיל מחדש את שירת השליחה. בדרך זו, בקשות ההעברה יישארו עם הכתובות המקוריות שלהן.

העברה של UDP ופרוטוקול PROXY

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

בשרור או בפרוקסי Minecraft שמקבל את התעבורה המעבה של UDP, יש ליצור את הקובץ config/raknetify2-proxy-protocol.json:

{
  "trustedProxies": ["192.0.2.10"]
}

החליפו את הדוגמה בכתובת IP האמיתית של הפרוקסי UDP או בסעיף CIDR שאתם שולטים. הכתובת חייבת להתאים לזה שרואה המשדר לאחר כל תהליך NAT. מקובלים רשומות IPv4 וIPv6. רשומות DNS נדחות. יש לזרוק את השרת המקבל או את הפרוקסי מחדש.

יש להגדיר את הפרוקסי של החיבור ההפניה כך שישלח את כותרות פרוטוקול PROXY v2 לחיבור UDP. Raknetify2 מקבל רק כתובות לקוחות שהופנו ממקורות המפורטים כאן. חיבורים ישירים ל-RakNet ללא כותרות אלו יידחו כאשר ההגדרה זו מופעלת. המאזין TCP שומר על ההגדרות הקיימות שלו.

אמון וגישה

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

הקובץ חייב להכיל רק רשומות של trustedProxies, עם לפחות רשומה אחת. ארכיון ריק הוא שגיאה. קובץ לא תקין מקטע את תהליך הפעלת רכז הקליטה של RakNet.

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

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

להתקנת פרוקסי של Minecraft ולהגדרת השרתים שמאחוריו, ראו Velocity ו־BungeeCord.

Simple Voice Chat

Raknetify2 יכול לשתף את מקש השמעות שלו בפרוטוקול UDP עם Simple Voice Chat בפלטפורמות Fabric, Forge, NeoForge, Spigot ו-Paper.

התקינו את Simple Voice Chat על הסרver ועל כל הלקוחות שרוצים שיחות קוליות. עקבו אחר ההנחיות של המדריך ל setup הסרver לגבי ההגדרות הנוספות.

השתמשו בקבוצת הקובצים config של השרת עבור הקובץ של Raknetify2, כולל ב-Spigot/Paper. הקובץ של Simple Voice Chat נשאר במקום המיועד לפלטפורמה הנתונה.

שתפו את העברת המשחק.

1. הקים את קובץ config/raknetify2-voicechat.json בדירוג השרת עם התוכן הבא:

   {"enabled": true}

2. הגדירו port=-1 בהגדרות השרת של Simple Voice Chat. בשרתים מודפסים, זה נמצא בconfig/voicechat/voicechat-server.properties. ב-Spigot/Paper, זה נמצא בplugins/voicechat/voicechat-server.properties.

3. השאירו את bind_address ריק אם יש לזה קולמן RakNet שמתאים. אם הסרviz מחזיק בכמה קולמן באותו שער UDP, שימו את זה לאדרסט הלקוח שאתם רוצים לשתף.

4. תחילו את השרת מחדש ובצעו /voicechat test <PLAYERNAME> עבור שחקן מחובר.

אם המאזין של RakNet משתמש ספק פקד שונה מזה של Minecraft, יש להגדיר את הפקד port לספק UDP המקומי בהתאם, במקום להשתמש ב-1. לדוגמה, מאזין RakNet על ספק UDP מקומי 25570 צריך port=25570.

הגדירו voice_host כאשר המשתמשים צריכים כתובת ציבורית או שער שונה. כדי שהרוטר יעביר את UDP הציבורי 25580 לשער UDP מקומי 25570, השתמשו בport=25570 ובvoice_host=play.example.com:25580. הכתובת הציבורית צריכה להיות בvoice_host. ההגדרה bind_address מבחר לקוח מקומי.

Raknetify2 מספק את תיבת UDP המשותפת דרך API של Simple Voice Chat. Simple Voice Chat מטפל באימות קול ובאקרנגולציה. השחקנים יכולים להשתמש בשיחות קול עם או עם חיבורי משחק TCP או RakNet.

שירותים ופרוקסיות אחרים של UDP

יש להשאיר את שדות ה-UDP של Query ו-Geyser נפרדים. האינטגרציה של הסוקטים המשותפים תומכת רק ב-Simple Voice Chat.

האינטגרציה אינה שותפת את תוף הפרוקסי של הקול ב-Velocity או ב-BungeeCord. עקבו אחר ההנחיות של פרוטוקול הפרוקסי של Simple Voice Chat ותנו לפרוקסי הקול את שער UDP משלו. באמצעות הפלטפורמה הרשמית לפרוקסי קול, הגדירו כל voice_host ציבורי בהגדרות הפרוקסי של הקול. פלטפורמה זו מתעלמת מההגדרות voice_host של שרתי ההמקור.

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

הפסיקו את שיתוף החומרים או פתרו סכסוך בסוגרת החיבור.

אם הרשומה מציגה את No RakNet listener matches the voice bind address and port, ודאו ש-RakNet התחיל בהצלחה, ושכתובת השידור וכתובת החיבור שלו תואמות את כתובת המאזין המקומי.

אם המסמך מציין Multiple RakNet listeners match the voice bind address, יש לבחור את הכתובת המקומית המתאימה בקובץ bind_address ולחדש את הפעולה.

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

כדי לבטל את השילוב של Raknetify2, יש להגדיר את {"enabled": false} בהגדרות הקול שלו, או להסיר את הקובץ הזה. יש להעניק ל-Simple Voice Chat פורט UDP נפרד, לעדכן את חסימות המארז שלו, ולתחיל את השרת מחדש.

טיפול בבעיות

TCP עובד, אך RakNet עוצר את העבודה.

בדקו אותם בסדר הבא:

1. הלקוח מחזיק במנוף Raknetify2 הנכון עבור גרסת ההגדרות וה-Minecraft שלו.
2. השרת או הפרוקסי שמקבל את ההתקשרות מכילים את Raknetify2 מותקנים ופועלים ללא שגיאות של מקשי הקלטה.
3. הכתובת מתחילה ב-raknet; ומשתמשת בפורט UDP ציבורי.
4. ספק האירוח, הרוטר ומחסום המחשב של המארח מאפשרים UDP באותו פורט.
5. כתובות ה-IPv4 וה-IPv6 של השם המארח מובילות לאותו מארח, ויש להן חוקי פרנטה שפועלים.

קישור TCP מוצלח רק מאשר את מסלול ה-TCP. עקבו אחר הגדרות פיירוול ורוטר כדי לבדוק את העברת UDP והגישה ל-IPv6. אם פרוטוקול PROXY מופעל, הלקוחות חייבים להגיע למאזין דרך פרוקסי אמין שגודל.

הכתובת כבר בשימוש.

בדקו אם תהליך אחר כבר משתמש ביציאת ה־UDP. ל־Query, ל־Geyser ולשירותי UDP אחרים דרושות יציאות משלהם. Simple Voice Chat יכול להשתמש באפשרות שיתוף היציאה.

ניתן לבחור פורט UDP מקומי אחר באמצעות הגדרות המאזין של השרת הישיר (direct-server listener settings) או את הגדרות Velocity וBungeeCord (Velocity and BungeeCord settings). יש לבדוק את דרישות הגרסה לגבי ההגדרה Spigot/Paper. שינוי רק בפורט הציבורי של הרוטר' ישאיר את הסוקט המקומי במצב של סכסוך.

הצטרפות עובדת, אך ההעברה נכשלת.

חברו ישירות למקום היעד באמצעות כתובת ה-raknet; שלו. אם זה לא עובד, תקנו קודם את המאזין של המקום היעד או את מסלול הרשת.

אם הקישורים הישירים עובדים, יש לבדוק האם היעד מקבל העברות. שרת Minecraft שמשתמש בserver.properties צריך להיות עם accepts-transfers=true. חיבורים ישירים אינם בודקים את ההגדרה הזו.

אז השוו את שם המחשב ותוף ה-TCP עם config/raknetify2-transfers.json במחשב השולח. ודאו שהקובץ נגרס לאחר הפעלה חדשה ושהלקוח תומך בהעברות אוטומטיות של RakNet. ראו העברות אוטומטיות.

שגיאות באנקורינג או בפרוטוקולים

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

כישלונות ספציפיים למדי של המדיום

ציינו איזו פעולה גורמת לתקלה, למשל פתיחת המלאי, קבלת חבילת משאבים, מעבר בין עולמות או יצירת ישות. במידת האפשר, בצעו את אותה פעולה בהתקנה נפרדת לבדיקה והשוו בין חיבור TCP לחיבור RakNet.

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

דווח על תקלה

פתחו תלונה ב-מערכת מעקב תלונות Raknetify2 וכללו:

• Minecraft, גרסאות Java, לודר וRaknetify2 בשני הצדדים.
• גרסאות תוכנות השרת והפרוקסי, כולל כל פרוקסי העברת UDP.
• מודים אחרים שמותקנו וגרסאותיהם.
• שלבים לחזקת הבעיה ומה שציפיתם שיקרה.
• האם אותם שלבים עובדים גם דרך TCP.
• קטעי רישומים רלוונטיים של הלקוח, השרת והפרוקסי מאותה ניסיון.

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

שילוב מודים

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

הזמנת קבוצות

קבוצה	תנועה קשורה
ui	מזרקות ואינטראקציות שאינן קשורות לעולם
entity	יצירת ישויות, הסרתן ותנועתן
world_interaction	אספקה ומגעים אחרים התלויים בעולם
effects	צלילים וחלקיקים
chunk	עדכונים בנוגע לטריין, לבלוקים ולאור.

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

אינטגרציה אפשרית של Fabric

הוסיפו ספקורר תחת הקטע raknetify:packet_channels ב-fabric.mod.json של המוד שלכם. הספקורר מממש את הערך Consumer<BiConsumer<String, String>> באמצעות סוגי קוד JDK. הוא מקבל רשום שמקבל מזהה של תוכן מותאם אישית וקבוצת סדרה.

שלבו את הרשומה הזו במטאדאטציות הקיימות שלכם, ובחליפת השם של הכיתה בשם המלא של הספק שלכם:

{
  "entrypoints": {
    "raknetify:packet_channels": [
      "com.example.mod.OrderingProvider"
    ]
  }
}

שמרו את שארית הקובץ fabric.mod.json, כולל פתחי הרשומות הקיימים בו. זהו קטע מהקובץ המטאדאטים.

לדוגמה, תוספת תנועה של ישות יכולה לרשום את example:entity_path לקבוצה entity. תיעוד ה-API של PacketOrdering כולל את היישום של הספקן.

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

התנהגות הרישום

למודים Forge ו-NeoForge, וגם פלגרים של שרת או פרוקסי, ניתן להשתמש ב-PacketOrdering.register(identifier, group) במהלך ההתחלת ההתקנה כאשר Raknetify2 זמין. התווית היא com.ishland.raknetify.api.PacketOrdering. יש להרשים את ההתווית לפני קבלת חיבורים של שחקנים, ולשמור על קודי השתלבות אופציונליים מבלי להגדיר את קלאסי Raknetify2 כאשר התלות אינה זמינה.

ההצהרות חלות על קישורים חדשים. הקישורים הקיימים שומרים על החוקים שקיבלו בתחילת השימוש. מותר לחזור על הצהרה זהה. קבוצות סותרות עבור אותו מזהה נדחות.

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

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

פרוקסיות UDP

ראו העברה של UDP ופרוטוקול PROXY לגבי מעבירי UDP וכתובות לקוחות מעובדות.

להגדרת פרוקסי של Minecraft, ראו Velocity ו־BungeeCord.

English (US)