Minecraft Velocity ქსელი: lobby, survival, მინიგეიმები

Minecraft-ის proxy რამდენიმე სერვერის წინ ერთ მისამართს აყენებს. მოთამაშეები უერთდებიან mc.example.com-ს, ხვდებიან lobby-ში და survival სამყაროდან, creative სამყაროდან ან მინიგეიმის სერვერზე გადადიან ბრძანებით /server survival ან პორტალში შესვლით - გათიშვის, მისამართის ხელახლა აკრეფის და ეკრანის გარეშე, რომელიც წერს "connecting to server". Velocity სწორედ ის proxy-ა, რომელიც უნდა აირჩიო. სწრაფია, აქტიურად მხარდაჭერილია და მისი modern forwarding რეჟიმი ერთადერთია, რომელიც ნაგულისხმევად უსაფრთხოა.

ეს არის სრული მოწყობა: რას აკეთებს და რას არ აკეთებს proxy, რომელი velocity.toml-ია მნიშვნელოვანი, forwarding secret და რატომ ტყდება ყოველი ქსელი მასზე ერთხელ მაინც, რა უნდა შეცვალო თითოეულ backend-ზე და როგორ ნაწილდება უფლებები და ჩატი, როცა ყველა backend ცალკე Minecraft სერვერია და საკუთარი წარმოდგენა აქვს იმაზე, ვინ ხარ.

რისთვის არის proxy და როდის არ გჭირდება#

Proxy არის Minecraft-ის პროტოკოლის reverse proxy. ის მოთამაშის კავშირს თავად ხურავს, მას ერთხელ ავთენტიფიცირებს, შემდეგ კი საკუთარ კავშირს ხსნის იმ backend-თან, რომელზეც მოთამაშე უნდა იყოს, და პაკეტებს ორივე მიმართულებით გადასცემს. სერვერის გადართვა ნიშნავს, რომ proxy ერთ backend კავშირს ხურავს, მეორეს ხსნის და მოთამაშის კავშირს ამასობაში ღიად ინახავს.

რას იღებ ამით:

• ერთი მისამართი და ერთი პორტი ნებისმიერი ზომის ქსელისთვის, ამიტომ მოთამაშეებმა mc.example.com-ზე მეტი არაფერი იციან.
• მყისიერი გადართვა სამყაროებს შორის, რომლებიც ცალკე სერვერის პროცესებია და თითოეულს საკუთარი მეხსიერება, საკუთარი plugin-ები და საკუთარი tick აქვს.
• დამოუკიდებელი მასშტაბირება. მინიგეიმის სერვერი შეიძლება გადაიტვირთოს და ქსელიდან არავინ გავიდეს, ხოლო ლაგიანი survival სამყარო lobby-ს არ ანელებს.
• მოთამაშეთა უფრო დიდი საერთო რაოდენობა, ვიდრე ერთ პროცესს შეუძლია tick-ში გაატაროს, რადგან სამუშაო რამდენიმე JVM-ზე ნაწილდება.
• ერთი ადგილი ქსელის მასშტაბის ამოცანებისთვის: სერვერთაშორისი ჩატი, რიგი, Bedrock-ის თარგმნა, ძველი კლიენტებისთვის პროტოკოლის თარგმნა.

რას არ იძლევა. Proxy ერთ სერვერს უფრო სწრაფს არ ხდის - 40 მოთამაშიანი survival სამყარო proxy-ს უკან ზუსტად იმდენივე დატვირთვაა, რამდენიც მის გარეშე. ის არ აზიარებს ინვენტარს, სახლებს, ბალანსს ან მიღწევებს; ყველა backend თავის მოთამაშის მონაცემებს ინახავს, სანამ რამეს არ დაამატებ, რაც მათ სინქრონიზაციას გააკეთებს. და ვერსიებს არ თარგმნის: კლიენტი და backend, რომელსაც ის ელაპარაკება, მაინც ერთი და იგივე Minecraft ვერსიის უნდა იყოს, რისთვისაც proxy-ზე ViaVersion არსებობს.

პატიოსანი ტესტი, გჭირდება თუ არა: თუ გაქვს ერთი სამყარო და დაახლოებით ორმოცზე ნაკლები მოთამაშე, არ გჭირდება. ჯერ tick გაასწორე Paper-ის ოპტიმიზაციის გზამკვლევით. Proxy მაშინ გჭირდება, როცა ერთი სახელის ქვეშ რამდენიმე განსხვავებული გამოცდილება გინდა, ან როცა ერთ პროცესს მოთამაშეების ატანა მართლა არ შეუძლია.

Velocity, BungeeCord და Waterfall#

სამი სახელი ისმის და მხოლოდ ერთია ამჟამინდელი პასუხი.

Velocity არის ნულიდან დაწერილი proxy საკუთარი plugin API-თი, შექმნილი გამტარუნარიანობისა და უსაფრთხოებისთვის. Modern forwarding, მისი ნაგულისხმევი რეკომენდაცია, მოთამაშის რეალურ იდენტობას backend-ს ხელმოწერილ payload-ში გადასცემს, ამიტომ backend-ს შეუძლია უარი თქვას ყველაფერზე, რაც proxy-ს გავლით არ მოსულა. Velocity 3-ს Java 17 ან უფრო ახალი სჭირდება.

BungeeCord არის ორიგინალი, კვლავ მხარდაჭერილია და კვლავ ძალიან ფართოდ გამოიყენება. მისი forwarding რეჟიმი ავთენტიფიკაციის გარეშეა: backend უბრალოდ ენდობა ნებისმიერ იდენტობას, რომელსაც კავშირი აცხადებს, სწორედ ამიტომ სჭირდება ყველა BungeeCord ქსელს firewall ან BungeeGuard plugin backend-ების წინ. Velocity ამ რეჟიმს საჭიროებისას ლაპარაკობს, როგორც legacy ან bungeeguard.

Waterfall იყო PaperMC-ის BungeeCord-ის fork. მას აღარ უჭერენ მხარს და თავად PaperMC-ის რჩევაა Velocity-ზე გადასვლა. ახალ ქსელს მასზე ნუ დაიწყებ.

Plugin-ები ამ სამს შორის არ გადადის. BungeeCord plugin Velocity-ზე ვერ იმუშავებს, ვერც Bukkit ან Paper plugin - proxy არ არის Minecraft სერვერი და არ აქვს სამყაროები, ბლოკები ან entity-ები, რომლებისთვისაც plugin API შეიძლება არსებობდეს. ქსელური plugin-ების უმეტესობას ორივე, BungeeCord-ისა და Velocity-ს, ვერსია აქვს.

Velocity-ის დაყენება და კონფიგურაცია, რომელიც მნიშვნელოვანია#

Velocity ერთი jar-ია. ჩამოტვირთე PaperMC-ის გვერდიდან, ჩადე ცარიელ დირექტორიაში და ერთხელ გაუშვი, რომ კონფიგურაცია შეიქმნას:

$ java -Xms512M -Xmx512M -XX:+UseG1GC -XX:MaxGCPauseMillis=100 \    -jar velocity.jar

ნახევარი გიგაბაიტი heap-ი რამდენიმე ასეულ მოთამაშეს მშვიდად უმკლავდება. Proxy-ს სამყარო არ უჭირავს და თითქმის არანაირი მდგომარეობა არ აქვს; ის CPU-ს ხარჯავს პაკეტების შეკუმშვასა და დაშიფვრაზე, ამიტომ ბირთვი მეტ მნიშვნელობას იძენს, ვიდრე მეხსიერება. Proxy პატარა აირჩიე, backend-ები - როგორც საჭიროა.

გენერირებული velocity.toml კარგად არის დაკომენტარებული. ეს არის ხაზები, რომლებიც უნდა შეცვალო:

bind = "0.0.0.0:25565"motd = "<gradient:#5A9BD5:#FFFFFF>The Longhouse Network</gradient>"show-max-players = 200online-mode = trueforce-key-authentication = trueplayer-info-forwarding-mode = "modern"forwarding-secret-file = "forwarding.secret"kick-existing-players = falseping-passthrough = "disabled"[servers]lobby = "10.0.0.11:25566"survival = "10.0.0.12:25567"minigames = "10.0.0.13:25568"try = ["lobby"][forced-hosts]"survival.example.com" = ["survival"]"minigames.example.com" = ["minigames"][advanced]compression-threshold = 256failover-on-unexpected-server-disconnect = truelog-player-connections = true[query]enabled = falseport = 25577

შენიშვნები იმ პარამეტრებზე, რომლებზეც ხალხი ებმევა:

• online-mode = true proxy-ზე უნდა იყოს და მხოლოდ proxy-ზე. ეს არის მთელი ქსელის ერთადერთი ავთენტიფიკაციის წერტილი. Backend-ები მას გამორთული აქვთ, რადგან მოთამაშეებისთვის პირდაპირ მისაწვდომი არ არის.
• player-info-forwarding-mode = "modern" არის პარამეტრი, რომელსაც ეს მთელი პოსტი ეძღვნება. მას backend-ზე Paper 1.13 ან უფრო ახალი სჭირდება. 1.12.2 და უფრო ძველი backend-ებისთვის ნაცვლად საჭიროა "legacy" ან "bungeeguard", იმ დამატებითი სიფრთხილით, რასაც ეს რეჟიმები მოითხოვს.
• try = ["lobby"] არის სერვერების დალაგებული სია, რომელზეც მოთამაშე შესვლისას იგზავნება. ჩაწერე მასში მეორე ელემენტი და proxy მას გადახტება, თუ პირველი გათიშულია.
• [forced-hosts] მარშრუტს ირჩევს იმ hostname-ის მიხედვით, რომელიც მოთამაშემ აკრიფა, ამიტომ survival.example.com მას პირდაპირ survival-ში აგდებს lobby-ში გაჩერების გარეშე. ყოველ ჩანაწერს საკუთარი DNS ჩანაწერი სჭირდება, რომელიც იმავე proxy-ზე მიუთითებს.
• ping-passthrough = "disabled" ნიშნავს, რომ სერვერების სიაში ჩანს proxy-ის საკუთარი MOTD და მოთამაშეთა რაოდენობა. დააყენე "description" ან "all", თუ backend-ის ჩვენება გირჩევნია.
• kick-existing-players = false ნიშნავს, რომ იმავე ანგარიშით მეორე შესვლას უარი ეთქმის. true ძველ სესიას აგდებს, რაც გინდა, თუ ქსელის მცირე შეფერხების შემდეგ მოთამაშეები ხშირად მოჩვენებებად რჩებიან.
• Velocity-ის motd იყენებს MiniMessage ფორმატირებას და არა იმ ძველ section კოდებს, რომლებსაც server.properties-ში იყენებ. Gradient-ები და hex ფერები აქ მუშაობს, იქ - არა.

Modern forwarding და secret ფაილი#

Modern forwarding ქსელს firewall-ის გარეშე უსაფრთხოს ხდის. როცა proxy backend-თან უკავშირდება, ის მოთამაშის რეალურ UUID-ს, სახელს, skin-ის თვისებებს და მისამართს გადასცემს საერთო secret-ით ხელმოწერილ payload-ში. Backend, რომელიც modern forwarding-ზეა გამართული, უარყოფს ყველა კავშირს, რომელსაც ვალიდური payload არ აქვს, რაც ნიშნავს, რომ მოთამაშე, რომელიც backend-ის მისამართსა და პორტს აღმოაჩენს, მასზე პირდაპირ ვერ შევა.

Secret ინახება velocity.toml-ის გვერდით ფაილში, რომლის სახელს forwarding-secret-file განსაზღვრავს. Velocity პირველ გაშვებაზე ერთს თავად ქმნის. წაიკითხე და იგივე სტრიქონი ჩასვი ყველა backend-ზე.

$ cat forwarding.secretkC7pQ2mZ9vXb4TfR

Paper backend-ებზე secret მიდის config/paper-global.yml-ში:

proxies:  velocity:    enabled: true    online-mode: true    secret: 'kC7pQ2mZ9vXb4TfR'

აქ online-mode დააყენე proxy-ის საკუთარი online-mode-ის შესაბამისად, რომელიც true უნდა იყოს. ეს Paper-ს ეუბნება, proxy-დან მოსული იდენტობები Mojang-თან მართლა გადამოწმდა თუ არა.

Modern forwarding-ს სჭირდება Paper, ან Fabric და Forge შესაბამისი proxy-თავსებადობის mod-ით. უბრალო Spigot ამას ვერ აკეთებს. თუ შენი backend Paper არ არის, ან გადაიყვანე Paper-ზე, ან დათანხმდი legacy forwarding-ს BungeeGuard-ითა და firewall-ით.

რა უნდა შეცვალო თითოეულ backend-ზე#

ყოველი backend ჩვეულებრივი Minecraft სერვერია ოთხი ცვლილებით.

server-port=25566online-mode=falseenforce-secure-profile=falsenetwork-compression-threshold=-1view-distance=6

online-mode=false აქ სწორია და მხოლოდ აქ. ავთენტიფიკაცია proxy-მ გააკეთა; backend იდენტობას ხელმოწერილი forwarding payload-იდან იღებს. ეს ამ პარამეტრის ერთადერთი კანონიერი გამოყენებაა და უსაფრთხოა სწორედ იმიტომ, რომ Paper-ის Velocity მხარდაჭერა ვალიდური payload-ის გარეშე კავშირებს უარყოფს. თუ online-mode=false დააყენე backend-ზე Velocity forwarding-ის ჩართვის გარეშე, გაქვს ღია სერვერი, რომელზეც ნებისმიერს შეუძლია ნებისმიერად შემოსვლა.

enforce-secure-profile=false backend-ს უშლის ხელს, მოითხოვოს ხელმოწერილი ჩატის პროფილი, რომლის გადამოწმებაც თავად არ შეუძლია.

network-compression-threshold=-1 გამორთავს შეკუმშვას proxy-სა და backend-ს შორის. ამის გაკეთება ღირს, როცა ისინი ერთ მანქანაზე ან ერთ ლოკალურ ქსელში არიან, რადგან proxy მოთამაშეებისკენ გამავალ ტრაფიკს უკვე ჭუმშავს და ორჯერ შეკუმშვა უბრალოდ CPU-ს წვავს. თუ backend-ები proxy-სგან ინტერნეტით არიან დაშორებული, დატოვე 256.

თითოეულ backend-ს სხვა პორტი მიეცი, ხოლო lobby-ს survival სამყაროზე გაცილებით მცირე მოცულობა: view-distance=5, simulation-distance=4, gamemode=adventure, spawn-protection ისეთი დიდი, რომ ნაგებობა დაფაროს, და 1-2 GB მეხსიერება. Lobby-ს, რომელსაც სიმულაციის არაფერი აქვს, არ სჭირდება ის, რაც survival სამყაროს.

უფლებები, ჩატი და მოთამაშის მონაცემები სერვერებს შორის#

ეს არის ნაწილი, რომელიც უკვირთ მათ, ვინც ელოდა, რომ proxy რამდენიმე სერვერს ერთივით აამუშავებდა. არ ამუშავებს. ყოველ backend-ს საკუთარი world/playerdata, საკუთარი ops.json და საკუთარი plugin-ების ბაზები აქვს. შედი survival-ზე და ამ ფაილების თვალსაზრისით ის ადამიანი აღარ ხარ, ვინც წამის წინ lobby-ში იყო.

რას ინაწილებ სინამდვილეში და როგორ:

• უფლებები. გაუშვი LuckPerms ყველა backend-ზე, ყველა ერთსა და იმავე ბაზაზე მიუთითე ლოკალური ფაილების ნაცვლად და ჩართე მისი messaging, რომ ცვლილება გადატვირთვის გარეშე გავრცელდეს. ეს სტანდარტული გადაწყვეტაა და კარგად მუშაობს. LuckPerms-ის გზამკვლევი აღწერს ჯგუფებს, მემკვიდრეობას და კონტექსტებს, რომლებიც რანგს სერვერის მიხედვით სხვადასხვა მნიშვნელობას აძლევს. RE:NODE-ზე ბაზის slot შედის თამაშის გეგმებში - პანელი host-ს, user-სა და პაროლს თავად აგენერირებს - და თუ ქსელის ბაზის ცალკე გაშვება გირჩევნია, database hosting გთავაზობს PostgreSQL-ს, რომელსაც LuckPerms პირდაპირ უჭერს მხარს.
• ჩატი. სერვერთაშორისი ჩატის plugin proxy-ზე ან ყველა backend-ზე საერთო არხით. მის გარეშე ყოველი backend-ის ჩატი კუნძულია.
• მოთამაშის ინვენტარი და ბალანსი. მხოლოდ plugin-ით, რომელიც მათ პირდაპირ სინქრონიზებს, და ყველა ასეთ plugin-ს აქვს ნივთების გაორმაგების შესაძლო ჩავარდნა, როცა სერვერი გადაცემის შუაში კრაშდება. უფრო უსაფრთხო დიზაინია ინვენტარი საერთოდ არ გააზიარო: lobby-ს არაფერი მისცე, თითოეულ რეჟიმს საკუთარი ეკონომიკა ჰქონდეს და დათანხმდე, რომ survival-ის აღჭურვილობა survival-ში რჩება. EssentialsX და საერთო ეკონომიკა აღწერს ბაზაზე დაფუძნებულ ვარიანტს, როცა ის მართლა გჭირდება.
• Whitelist-ები. Modern forwarding-ით რეალური UUID თითოეულ backend-ს აღწევს, ამიტომ backend-ის whitelist.json ჩვეულებრივად მუშაობს. ქსელის მასშტაბის whitelist უფრო მარტივი სამართავია proxy-დან plugin-ით.

Velocity-ის საკუთარი ბრძანებები მოკლეა და თითოეულს აქვს permission node, რომ LuckPerms-ით გასცე:

/velocity reload დამატებულ და წაშლილ სერვერებს მიერთებული მოთამაშეების გათიშვის გარეშე ითვალისწინებს, რის გამოც მეოთხე backend-ის დამატება არაფრისმომცემი ამბავია.

პორტები, მისამართები და საჯარო სახე#

მიუთითე A ჩანაწერი proxy-ზე, შემდეგ დაამატე SRV ჩანაწერი, რომ მოთამაშეებმა mc.example.com პორტის გარეშე აკრიფონ. SRV ჩანაწერები Minecraft-ისთვის შეიცავს ზუსტ ჩანაწერს და გავრცელებულ შეცდომებს; ქვედომენები სერვერებისთვის აღწერს backend-ების hostname-ებს, რომლებიც [forced-hosts]-ს სჭირდება. Backend-ებს საჯარო DNS საერთოდ არ სჭირდებათ და მათთვის დასამახსოვრებელი hostname-ების მიცემა მხოლოდ იმას ეხმარება, რომ ხალხმა ისინი იპოვოს.

პანელ ჰოსტზე ქსელი ერთი ფასიანი სერვერია თითო პროცესზე, რაც პირდაპირ უნდა ითქვას: proxy და სამი backend ოთხი სერვერია. Proxy მათგან ყველაზე იაფია, რადგან ძალიან ცოტა მეხსიერება სჭირდება. RE:NODE-ის Minecraft გეგმები იწყება 2 GB-დან, თითო port allocation-ით, და მეტი პორტი შეიძლება დაემატოს Network ჩანართზე; პანელის სერვერზე მიბმული SFTP მონაცემები და ფაილების რედაქტორი არის ის, რითაც ერთსა და იმავე forwarding.secret-ს თითოეულ backend-ზე ატვირთავ, ხოლო Schedules ჩანართს შეუძლია მინიგეიმის სერვერი ყოველ ღამე გადატვირთოს ისე, რომ ვერავინ შეამჩნიოს, რადგან proxy ყველას კავშირს ინახავს.

Bedrock მოთამაშეებისთვის Geyser და Floodgate ეშვება proxy-ზე და არა თითოეულ backend-ზე, რაც ერთ-ერთი საუკეთესო არგუმენტია იმისა, რომ proxy ერთი სერვერის წინაც კი დააყენო - იხილე Geyser და Bedrock crossplay.

რა ტყდება და როგორ გამოიყურება შეცდომა#

`Your server did not send a forwarding request to the proxy. Is it set up correctly?` Velocity-ის კონსოლში. Backend modern forwarding-ზე არ არის გამართული: proxies.velocity.enabled ჯერ კიდევ false-ია, ან backend Paper არ არის, ან ცვლილების შემდეგ არ გადაიტვირთა.

მოთამაშეები მაშინვე გაგდებულნი არიან forwarding-ის ან decoder-ის შეცდომით. Secret არ ემთხვევა. შეადარე ორი სტრიქონი სიმბოლო-სიმბოლო და შეამოწმე ფაილში ბოლოს ახალი ხაზი ან კოპირებისას მოყოლილი ჰარი.

`Unable to connect you to survival` მოთამაშეს ეჩვენება, ხოლო proxy-ის ლოგში connection-refused გამონაკლისია. Backend გათიშულია, სხვა პორტზეა, ან მისამართზეა მიბმული, რომელსაც proxy ვერ წვდება. სანამ forwarding-ს დაადანაშაულებ, სცადე backend-ის მისამართი და პორტი proxy-ის საკუთარი shell-იდან.

Backend-თან პირდაპირი კავშირი წარმატებულია. გაჩერდი და ეს გაასწორე, სანამ რამეს გამოაცხადებ. ეს ნიშნავს, რომ forwarding ამ backend-ზე გამორთულია ან არასწორად არის გამართული, და online-mode=false-ის პირობებში ნებისმიერს შეუძლია მასზე ნებისმიერი მოთამაშის სახელით შესვლა, ოპერატორის ჩათვლით.

ყველა ახალ მოთამაშედ ჩანს ცარიელი ინვენტარით. UUID-ები offline-mode ფორმით მოდის, ანუ forwarding მართლა არ მუშაობს, თუნდაც მოთამაშეებს შეეძლოთ შესვლა. ასე გამოიყურება legacy forwarding BungeeGuard-ის გარეშე და ამიტომაა რეჟიმი მნიშვნელოვანი.

`You are already connected to this proxy!` გაწყვეტილი კავშირისგან დარჩენილი მოჩვენება სესია. velocity.toml-ში kick-existing-players = true ახალ შესვლას გამარჯვებას აძლევს.

ვერსიების შეუსაბამობა ერთ backend-ზე განახლების შემდეგ. Velocity პროტოკოლს გადასცემს და არ თარგმნის. 1.21 კლიენტი 1.20 backend-ს proxy-ს გავლით ისევე ვერ შეუერთდება, როგორც პირდაპირ. ან ყველა backend ერთ ვერსიაზე დაიჭირე, ან proxy-ზე ViaVersion დააყენე. Minecraft-ის ვერსიების განახლებები აღწერს სწორ თანმიმდევრობას, რაც ქსელზე ასეთია: ჯერ proxy-ის plugin-ები, შემდეგ lobby, დანარჩენი ყველაფერი ბოლოს.

Plugin messaging წყვეტს მუშაობას. ყველაფერს, რაც BungeeCord plugin channel-ს იყენებს, სჭირდება bungee-plugin-message-channel = true [advanced] სექციაში, რაც ნაგულისხმევია. ჩვეულებრივ ზარალდებიან plugin-ები, რომლებიც მას მონაცემების ნაცვლად ბრძანებებისთვის იყენებდნენ.

FAQ#

მჭირდება proxy ორი სერვერისთვის?

მხოლოდ მაშინ, თუ გინდა მოთამაშეები მათ შორის გათიშვის გარეშე გადადიოდნენ, ან ორივე ერთ მისამართზე გინდა. ორი ცალკე მისამართი არაფერი ღირს და არაფერს არღვევს. Proxy თავის ადგილს იმსახურებს, როცა გადართვა უწყვეტი უნდა იყოს ან როცა lobby გამოცდილების ნაწილია.

ამცირებს proxy ლაგს?

არა. ყოველი პაკეტი ერთ დამატებით გადასვლას გადის, ამიტომ დაყოვნება ოდნავ იზრდება. Proxy გაძლევს საშუალებას, სამუშაო რამდენიმე პროცესზე გაანაწილო, რომ თითოეულს მთელი tick-ის ბიუჯეტი ჰქონდეს. თუ ერთი სამყარო ლაგავს, proxy მას არ დაეხმარება.

შემიძლია Velocity იმავე მანქანაზე გავუშვა, რაზეც backend?

დიახ, ეს ჩვეულებრივი მოწყობაა. Proxy-ს მიეცი საკუთარი პატარა container ან პროცესი, backend მიაბი პორტზე, რომელსაც proxy წვდება, და backend-ზე დააყენე network-compression-threshold=-1, რადგან ტრაფიკი მანქანას არ ტოვებს.

უსაფრთხოა backend-ებზე online-mode=false?

მხოლოდ გამართული და გადამოწმებული forwarding-ით. Paper backend-ზე modern forwarding-ის ჩართვისას კავშირები, რომლებსაც შენი proxy-დან ვალიდური ხელმოწერილი payload არ აქვს, უარყოფილია, ამიტომ backend ღია არ არის. მის გარეშე offline-mode backend საჯარო პორტით Minecraft ჰოსტინგის ყველაზე საშიში კონფიგურაციაა.

როგორ გავუზიარო ინვენტარი სერვერებს შორის?

Plugin-ით, რომელიც მათ პირდაპირ საერთო ბაზაში სინქრონიზებს, იმის გაცნობიერებით, რომ ყველა ასეთ plugin-ს შეუძლია ნივთები გააორმაგოს, თუ სერვერი უარეს მომენტში გაითიშება. ბევრი კარგად მართული ქსელი განზრახ არ ინაწილებს ინვენტარს და თითოეულ რეჟიმს საკუთარს აძლევს, რაც ჩავარდნის ამ სცენარს მთლიანად აქრობს.

უნდა გამოვიყენო BungeeCord-ი?

ახალი ქსელისთვის არა. Velocity უფრო სწრაფია, მისი modern forwarding დამატებითი plugin-ების გარეშე უსაფრთხოა და ის არის proxy, რომელზეც PaperMC ახლა მიუთითებს, რადგან Waterfall დასრულდა. BungeeCord-ის არჩევის ერთადერთი მიზეზია plugin, რომლის გარეშეც ვერ ძლებ და Velocity ვერსია არ აქვს.