ভূমিকা

আমাদের প্রতিষ্ঠান লীনিং টেকনোলজিস ওয়েবে ঐতিহ্যগত ডেস্কটপ অ্যাপ্লিকেশন পোর্ট করার জন্য সমাধান প্রদান করে। আমাদের C++ কম্পাইলার উল্লাস WebAssembly এবং JavaScript এর সমন্বয় তৈরি করে, যা উভয়ই প্রদান করে সহজ ব্রাউজার মিথস্ক্রিয়া, এবং উচ্চ কর্মক্ষমতা.

এর প্রয়োগের উদাহরণ হিসাবে, আমরা ওয়েবে একটি মাল্টিপ্লেয়ার গেম পোর্ট করার সিদ্ধান্ত নিয়েছি এবং বেছে নিয়েছি Teeworlds. Teeworlds হল একটি মাল্টিপ্লেয়ার XNUMXD রেট্রো গেম যেখানে একটি ছোট কিন্তু সক্রিয় খেলোয়াড়দের সম্প্রদায় (আমি সহ!) এটি ডাউনলোড করা সম্পদ এবং CPU এবং GPU প্রয়োজনীয়তা উভয় ক্ষেত্রেই ছোট - একজন আদর্শ প্রার্থী।

Teeworlds ব্রাউজারে চলছে

আমরা পরীক্ষা করার জন্য এই প্রকল্পটি ব্যবহার করার সিদ্ধান্ত নিয়েছি ওয়েবে নেটওয়ার্ক কোড পোর্ট করার জন্য সাধারণ সমাধান. এটি সাধারণত নিম্নলিখিত উপায়ে করা হয়:

• XMLHttpঅনুরোধ/আনয়ন, যদি নেটওয়ার্ক অংশে শুধুমাত্র HTTP অনুরোধ থাকে, বা
• ওয়েবসকেট.

উভয় সমাধানের জন্য সার্ভারের পাশে একটি সার্ভার উপাদান হোস্ট করা প্রয়োজন, এবং একটি পরিবহন প্রোটোকল হিসাবে ব্যবহারের অনুমতি দেয় না এর ফলে UDP. এটি ভিডিও কনফারেন্সিং সফ্টওয়্যার এবং গেমগুলির মতো রিয়েল-টাইম অ্যাপ্লিকেশনগুলির জন্য গুরুত্বপূর্ণ, কারণ এটি প্রোটোকল প্যাকেটগুলির বিতরণ এবং অর্ডারের গ্যারান্টি দেয় বিভিন্ন TCP কম বিলম্বে বাধা হয়ে উঠতে পারে।

একটি তৃতীয় উপায় আছে - ব্রাউজার থেকে নেটওয়ার্ক ব্যবহার করুন: WebRTC এর.

RTCDataChannel এটি নির্ভরযোগ্য এবং অবিশ্বস্ত উভয় ট্রান্সমিশন সমর্থন করে (পরবর্তী ক্ষেত্রে এটি যখনই সম্ভব একটি পরিবহন প্রোটোকল হিসাবে UDP ব্যবহার করার চেষ্টা করে), এবং একটি দূরবর্তী সার্ভার এবং ব্রাউজারগুলির মধ্যে উভয়ই ব্যবহার করা যেতে পারে। এর মানে হল যে আমরা সার্ভার কম্পোনেন্ট সহ পুরো অ্যাপ্লিকেশনটিকে ব্রাউজারে পোর্ট করতে পারি!

যাইহোক, এটি একটি অতিরিক্ত অসুবিধার সাথে আসে: দুই WebRTC সহকর্মী যোগাযোগ করার আগে, তাদের সংযোগ করার জন্য একটি তুলনামূলকভাবে জটিল হ্যান্ডশেক করতে হবে, যার জন্য বেশ কয়েকটি তৃতীয় পক্ষের সত্তার প্রয়োজন (একটি সিগন্যালিং সার্ভার এবং এক বা একাধিক সার্ভার) STUN/চালু).

আদর্শভাবে, আমরা একটি নেটওয়ার্ক API তৈরি করতে চাই যেটি অভ্যন্তরীণভাবে WebRTC ব্যবহার করে, কিন্তু একটি UDP সকেট ইন্টারফেসের যতটা সম্ভব কাছাকাছি যার কোনো সংযোগ স্থাপনের প্রয়োজন নেই।

এটি আমাদেরকে অ্যাপ্লিকেশন কোডে জটিল বিশদ প্রকাশ না করেই WebRTC-এর সুবিধা গ্রহণ করার অনুমতি দেবে (যা আমরা আমাদের প্রকল্পে যতটা সম্ভব কম পরিবর্তন করতে চেয়েছিলাম)।

ন্যূনতম WebRTC

WebRTC হল ব্রাউজারে উপলব্ধ API-এর একটি সেট যা অডিও, ভিডিও এবং নির্বিচারে ডেটার পিয়ার-টু-পিয়ার ট্রান্সমিশন প্রদান করে।

আইসিই নামক একটি প্রক্রিয়ার মাধ্যমে STUN এবং/অথবা টার্ন সার্ভার ব্যবহার করে সমবয়সীদের মধ্যে সংযোগ স্থাপন করা হয় (এমনকি এক বা উভয় দিকে NAT থাকলেও)। সহকর্মীরা SDP প্রোটোকলের অফার এবং উত্তরের মাধ্যমে ICE তথ্য এবং চ্যানেল প্যারামিটার বিনিময় করে।

কি দারুন! এক সময়ে কয়টি সংক্ষিপ্ত রূপ? আসুন সংক্ষেপে ব্যাখ্যা করি এই পদগুলির অর্থ কী:

• NAT-এর জন্য সেশন ট্রাভার্সাল ইউটিলিটি (STUN) — NAT বাইপাস করার এবং হোস্টের সাথে সরাসরি ডেটা আদান-প্রদানের জন্য একটি জোড়া (IP, পোর্ট) পাওয়ার জন্য একটি প্রোটোকল। যদি তিনি তার কাজটি সম্পূর্ণ করতে পরিচালনা করেন, তবে সহকর্মীরা একে অপরের সাথে স্বাধীনভাবে ডেটা বিনিময় করতে পারে।
• NAT এর চারপাশে রিলে ব্যবহার করে ট্রাভার্সাল (চালু) NAT ট্রাভার্সালের জন্যও ব্যবহার করা হয়, কিন্তু এটি একটি প্রক্সির মাধ্যমে ডেটা ফরওয়ার্ড করার মাধ্যমে এটি প্রয়োগ করে যা উভয় সমকক্ষের কাছে দৃশ্যমান। এটি লেটেন্সি যোগ করে এবং STUN এর তুলনায় এটি বাস্তবায়ন করা আরও ব্যয়বহুল (কারণ এটি সমগ্র যোগাযোগ সেশন জুড়ে প্রয়োগ করা হয়), তবে কখনও কখনও এটি একমাত্র বিকল্প।
• ইন্টারেক্টিভ সংযোগ স্থাপন (বরফ) সরাসরি সংযোগকারী সমবয়সীদের থেকে প্রাপ্ত তথ্য, সেইসাথে যেকোন সংখ্যক STUN এবং TURN সার্ভারের দ্বারা প্রাপ্ত তথ্যের উপর ভিত্তি করে দুটি পিয়ারকে সংযুক্ত করার সর্বোত্তম সম্ভাব্য পদ্ধতি নির্বাচন করতে ব্যবহৃত হয়।
• সেশন বর্ণনা প্রোটোকল (আভ্যন্তরীন উৎপাদন) সংযোগ চ্যানেল পরামিতি বর্ণনা করার জন্য একটি বিন্যাস, উদাহরণস্বরূপ, ICE প্রার্থী, মাল্টিমিডিয়া কোডেক (একটি অডিও/ভিডিও চ্যানেলের ক্ষেত্রে), ইত্যাদি... সহকর্মীদের মধ্যে একজন একটি SDP অফার পাঠায়, এবং দ্বিতীয়টি একটি SDP উত্তর দিয়ে প্রতিক্রিয়া জানায় .. এর পরে, একটি চ্যানেল তৈরি করা হয়।

এই ধরনের সংযোগ তৈরি করতে, সহকর্মীদের STUN এবং TURN সার্ভার থেকে প্রাপ্ত তথ্য সংগ্রহ করতে হবে এবং একে অপরের সাথে বিনিময় করতে হবে।

সমস্যা হল যে তাদের এখনও সরাসরি যোগাযোগ করার ক্ষমতা নেই, তাই এই ডেটা আদান-প্রদানের জন্য একটি আউট-অফ-ব্যান্ড মেকানিজম থাকতে হবে: একটি সিগন্যালিং সার্ভার।

একটি সিগন্যালিং সার্ভার খুব সহজ হতে পারে কারণ এর একমাত্র কাজ হ্যান্ডশেক পর্বে সহকর্মীদের মধ্যে ডেটা ফরওয়ার্ড করা (নিচের চিত্রে দেখানো হয়েছে)।

সরলীকৃত WebRTC হ্যান্ডশেক সিকোয়েন্স ডায়াগ্রাম

Teeworlds নেটওয়ার্ক মডেল ওভারভিউ

Teeworlds নেটওয়ার্ক আর্কিটেকচার খুবই সহজ:

• ক্লায়েন্ট এবং সার্ভার উপাদান দুটি ভিন্ন প্রোগ্রাম।
• ক্লায়েন্টরা একাধিক সার্ভারের একটিতে সংযোগ করে গেমটিতে প্রবেশ করে, যার প্রত্যেকটি একবারে একটি মাত্র গেম হোস্ট করে।
• গেমের সমস্ত ডেটা স্থানান্তর সার্ভারের মাধ্যমে করা হয়।
• গেম ক্লায়েন্টে প্রদর্শিত সমস্ত পাবলিক সার্ভারের একটি তালিকা সংগ্রহ করতে একটি বিশেষ মাস্টার সার্ভার ব্যবহার করা হয়।

ডেটা আদান-প্রদানের জন্য WebRTC ব্যবহার করার জন্য ধন্যবাদ, আমরা গেমের সার্ভার উপাদানটি ব্রাউজারে স্থানান্তর করতে পারি যেখানে ক্লায়েন্ট অবস্থিত। এটি আমাদের একটি দুর্দান্ত সুযোগ দেয় ...

সার্ভার থেকে পরিত্রাণ পান

সার্ভার লজিকের অভাবের একটি চমৎকার সুবিধা রয়েছে: আমরা সম্পূর্ণ অ্যাপ্লিকেশনটিকে স্থির বিষয়বস্তু হিসাবে Github পৃষ্ঠাগুলিতে বা Cloudflare-এর পিছনে আমাদের নিজস্ব হার্ডওয়্যারে স্থাপন করতে পারি, এইভাবে বিনামূল্যে দ্রুত ডাউনলোড এবং উচ্চ আপটাইম নিশ্চিত করতে পারি। আসলে, আমরা তাদের সম্পর্কে ভুলে যেতে পারি, এবং যদি আমরা ভাগ্যবান হই এবং গেমটি জনপ্রিয় হয়ে ওঠে, তবে অবকাঠামো আধুনিকীকরণ করতে হবে না।

যাইহোক, সিস্টেমটি কাজ করার জন্য, আমাদের এখনও একটি বাহ্যিক আর্কিটেকচার ব্যবহার করতে হবে:

• এক বা একাধিক STUN সার্ভার: আমাদের কাছে বেছে নেওয়ার জন্য অনেকগুলি বিনামূল্যের বিকল্প রয়েছে৷
• কমপক্ষে একটি টার্ন সার্ভার: এখানে কোন বিনামূল্যের বিকল্প নেই, তাই আমরা হয় আমাদের নিজস্ব সেট আপ করতে পারি বা পরিষেবার জন্য অর্থ প্রদান করতে পারি৷ সৌভাগ্যবশত, বেশিরভাগ সময় STUN সার্ভারের মাধ্যমে সংযোগ স্থাপন করা যেতে পারে (এবং সত্যিকারের p2p প্রদান করে), কিন্তু একটি ফলব্যাক বিকল্প হিসাবে টার্ন প্রয়োজন।
• সিগন্যালিং সার্ভার: অন্য দুটি দিক থেকে ভিন্ন, সিগন্যালিং মানসম্মত নয়। সিগন্যালিং সার্ভার আসলে কি জন্য দায়ী হবে তা কিছুটা প্রয়োগের উপর নির্ভর করে। আমাদের ক্ষেত্রে, সংযোগ স্থাপন করার আগে, অল্প পরিমাণে ডেটা বিনিময় করা প্রয়োজন।
• টিওয়ার্ল্ডস মাস্টার সার্ভার: এটি অন্যান্য সার্ভার দ্বারা তাদের অস্তিত্বের বিজ্ঞাপন দিতে এবং ক্লায়েন্টদের দ্বারা সর্বজনীন সার্ভারগুলি খুঁজে পেতে ব্যবহার করা হয়। যদিও এটির প্রয়োজন হয় না (ক্লায়েন্টরা সর্বদা একটি সার্ভারের সাথে সংযোগ করতে পারে যা তারা ম্যানুয়ালি জানে), এটি ভাল হবে যাতে খেলোয়াড়রা এলোমেলো লোকদের সাথে গেমগুলিতে অংশগ্রহণ করতে পারে।

আমরা Google-এর বিনামূল্যের STUN সার্ভারগুলি ব্যবহার করার সিদ্ধান্ত নিয়েছি, এবং নিজেরাই একটি টার্ন সার্ভার স্থাপন করেছি৷

শেষ দুটি পয়েন্টের জন্য আমরা ব্যবহার করেছি Firebase:

• Teeworlds মাস্টার সার্ভারটি খুব সহজভাবে প্রয়োগ করা হয়েছে: প্রতিটি সক্রিয় সার্ভারের তথ্য (নাম, আইপি, মানচিত্র, মোড, ...) ধারণকারী বস্তুর তালিকা হিসাবে। সার্ভারগুলি তাদের নিজস্ব বস্তু প্রকাশ করে এবং আপডেট করে এবং ক্লায়েন্টরা সম্পূর্ণ তালিকা নেয় এবং প্লেয়ারের কাছে প্রদর্শন করে। এছাড়াও আমরা হোম পেজে তালিকাটি HTML হিসাবে প্রদর্শন করি যাতে খেলোয়াড়রা কেবল সার্ভারে ক্লিক করতে পারে এবং সরাসরি গেমে নিয়ে যেতে পারে।
• সিগন্যালিং আমাদের সকেট বাস্তবায়নের সাথে ঘনিষ্ঠভাবে সম্পর্কিত, পরবর্তী বিভাগে বর্ণিত।

গেমের ভিতরে এবং হোম পেজে সার্ভারের তালিকা

সকেট বাস্তবায়ন

আমরা এমন একটি API তৈরি করতে চাই যা Posix UDP সকেটের যতটা সম্ভব কাছাকাছি, প্রয়োজনীয় পরিবর্তনের সংখ্যা কমিয়ে আনতে।

আমরা নেটওয়ার্কের মাধ্যমে সহজতম ডেটা বিনিময়ের জন্য প্রয়োজনীয় ন্যূনতম প্রয়োজনীয়তা বাস্তবায়ন করতে চাই।

উদাহরণস্বরূপ, আমাদের প্রকৃত রাউটিং প্রয়োজন নেই: সমস্ত সহকর্মীরা একটি নির্দিষ্ট ফায়ারবেস ডাটাবেস উদাহরণের সাথে যুক্ত একই "ভার্চুয়াল LAN" এ রয়েছে৷

অতএব, আমাদের অনন্য আইপি ঠিকানার প্রয়োজন নেই: অনন্য ফায়ারবেস কী মান (ডোমেন নামের অনুরূপ) অনন্যভাবে সমকক্ষদের সনাক্ত করার জন্য যথেষ্ট, এবং প্রতিটি পিয়ার স্থানীয়ভাবে প্রতিটি কীকে অনুবাদ করার প্রয়োজনে "জাল" আইপি ঠিকানাগুলি বরাদ্দ করে৷ এটি সম্পূর্ণরূপে গ্লোবাল আইপি অ্যাড্রেস অ্যাসাইনমেন্টের প্রয়োজনীয়তা দূর করে, যা একটি অ-তুচ্ছ কাজ।

এখানে ন্যূনতম API যা আমাদের বাস্তবায়ন করতে হবে:

// Create and destroy a socket
int socket();
int close(int fd);
// Bind a socket to a port, and publish it on Firebase
int bind(int fd, AddrInfo* addr);
// Send a packet. This lazily create a WebRTC connection to the 
// peer when necessary
int sendto(int fd, uint8_t* buf, int len, const AddrInfo* addr);
// Receive the packets destined to this socket
int recvfrom(int fd, uint8_t* buf, int len, AddrInfo* addr);
// Be notified when new packets arrived
int recvCallback(Callback cb);
// Obtain a local ip address for this peer key
uint32_t resolve(client::String* key);
// Get the peer key for this ip
String* reverseResolve(uint32_t addr);
// Get the local peer key
String* local_key();
// Initialize the library with the given Firebase database and 
// WebRTc connection options
void init(client::FirebaseConfig* fb, client::RTCConfiguration* ice);

এপিআই সহজ এবং পসিক্স সকেটস এপিআই এর মতো, তবে এর কয়েকটি গুরুত্বপূর্ণ পার্থক্য রয়েছে: কলব্যাক লগ করা, স্থানীয় আইপি বরাদ্দ করা এবং অলস সংযোগ.

কলব্যাক নিবন্ধন

এমনকি যদি মূল প্রোগ্রামটি নন-ব্লকিং I/O ব্যবহার করে, কোডটি ওয়েব ব্রাউজারে চালানোর জন্য রিফ্যাক্টর করা আবশ্যক।

এর কারণ হল ব্রাউজারে ইভেন্ট লুপ প্রোগ্রাম থেকে লুকানো থাকে (সেটি JavaScript বা WebAssembly হোক)।

দেশীয় পরিবেশে আমরা এভাবে কোড লিখতে পারি

while(running) {
  select(...); // wait for I/O events
  while(true) {
    int r = readfrom(...); // try to read
    if (r < 0 && errno == EWOULDBLOCK) // no more data available
      break;
    ...
  }
  ...
}

যদি ইভেন্ট লুপটি আমাদের কাছে লুকানো থাকে, তাহলে আমাদের এটিকে এরকম কিছুতে পরিণত করতে হবে:

auto cb = []() { // this will be called when new data is available
  while(true) {
    int r = readfrom(...); // try to read
    if (r < 0 && errno == EWOULDBLOCK) // no more data available
      break;
    ...
  }
  ...
};
recvCallback(cb); // register the callback

স্থানীয় আইপি অ্যাসাইনমেন্ট

আমাদের "নেটওয়ার্ক"-এর নোড আইডিগুলি আইপি ঠিকানা নয়, কিন্তু ফায়ারবেস কী (এগুলি এমন স্ট্রিং যা দেখতে এইরকম: -LmEC50PYZLCiCP-vqde ).

এটি সুবিধাজনক কারণ আইপি বরাদ্দ করা এবং তাদের স্বতন্ত্রতা পরীক্ষা করার জন্য আমাদের কোনও পদ্ধতির প্রয়োজন নেই (সেইসাথে ক্লায়েন্ট সংযোগ বিচ্ছিন্ন হওয়ার পরে তাদের নিষ্পত্তি করা), তবে এটি প্রায়শই একটি সংখ্যাসূচক মান দ্বারা সমবয়সীদের সনাক্ত করা প্রয়োজন।

এটি ঠিক কি ফাংশন জন্য ব্যবহার করা হয়. resolve и reverseResolve: অ্যাপ্লিকেশনটি কোনোভাবে কীটির স্ট্রিং মান (ব্যবহারকারীর ইনপুট বা মাস্টার সার্ভারের মাধ্যমে) গ্রহণ করে এবং অভ্যন্তরীণ ব্যবহারের জন্য এটিকে একটি আইপি ঠিকানায় রূপান্তর করতে পারে। বাকি এপিআইও সরলতার জন্য একটি স্ট্রিংয়ের পরিবর্তে এই মানটি গ্রহণ করে।

এটি DNS লুকআপের অনুরূপ, তবে ক্লায়েন্টে স্থানীয়ভাবে সঞ্চালিত হয়।

অর্থাৎ, আইপি ঠিকানাগুলি বিভিন্ন ক্লায়েন্টের মধ্যে ভাগ করা যায় না এবং যদি কিছু ধরণের গ্লোবাল আইডেন্টিফায়ার প্রয়োজন হয় তবে এটি অন্যভাবে তৈরি করতে হবে।

অলস সংযোগ

UDP-এর কোনো সংযোগের প্রয়োজন নেই, কিন্তু আমরা যেমনটি দেখেছি, WebRTC-এর দুটি সমকক্ষের মধ্যে ডেটা স্থানান্তর শুরু করার আগে একটি দীর্ঘ সংযোগ প্রক্রিয়া প্রয়োজন।

যদি আমরা একই স্তরের বিমূর্ততা প্রদান করতে চাই, (sendto/recvfrom পূর্বের সংযোগ ছাড়াই স্বেচ্ছাচারী সহকর্মীদের সাথে), তারপর তাদের অবশ্যই API-এর ভিতরে একটি "অলস" (বিলম্বিত) সংযোগ সম্পাদন করতে হবে৷

ইউডিপি ব্যবহার করার সময় "সার্ভার" এবং "ক্লায়েন্ট" এর মধ্যে স্বাভাবিক যোগাযোগের সময় এটি ঘটে এবং আমাদের লাইব্রেরির কী করা উচিত:

• সার্ভার কল bind()অপারেটিং সিস্টেমকে জানাতে যে এটি নির্দিষ্ট পোর্টে প্যাকেট পেতে চায়।

পরিবর্তে, আমরা সার্ভার কী-এর অধীনে ফায়ারবেসে একটি খোলা পোর্ট প্রকাশ করব এবং এর সাবট্রিতে ইভেন্টগুলি শুনব।

• সার্ভার কল recvfrom(), এই পোর্টে যেকোন হোস্ট থেকে আসা প্যাকেট গ্রহণ করা।

আমাদের ক্ষেত্রে, আমাদের এই বন্দরে পাঠানো প্যাকেটের ইনকামিং সারি চেক করতে হবে।

প্রতিটি পোর্টের নিজস্ব সারি আছে, এবং আমরা WebRTC ডেটাগ্রামের শুরুতে উৎস এবং গন্তব্য পোর্ট যোগ করি যাতে আমরা জানতে পারি যে যখন একটি নতুন প্যাকেট আসবে তখন কোন সারিতে ফরওয়ার্ড করতে হবে।

কলটি নন-ব্লকিং, তাই যদি কোনও প্যাকেট না থাকে, আমরা কেবল -1 ফেরত দিয়ে সেট করি errno=EWOULDBLOCK.

• ক্লায়েন্ট কিছু বাহ্যিক উপায়ে সার্ভারের আইপি এবং পোর্ট গ্রহণ করে এবং কল করে sendto(). এটি একটি অভ্যন্তরীণ কলও করে। bind(), তাই পরবর্তী recvfrom() স্পষ্টভাবে বাইন্ড কার্যকর না করেই প্রতিক্রিয়া পাবেন।

আমাদের ক্ষেত্রে, ক্লায়েন্ট বাহ্যিকভাবে স্ট্রিং কী গ্রহণ করে এবং ফাংশন ব্যবহার করে resolve() একটি আইপি ঠিকানা পেতে।

এই মুহুর্তে, আমরা একটি WebRTC হ্যান্ডশেক শুরু করি যদি দুটি সহকর্মী এখনও একে অপরের সাথে সংযুক্ত না থাকে। একই পিয়ারের বিভিন্ন পোর্টের সাথে সংযোগ একই WebRTC DataChannel ব্যবহার করে।

আমরা পরোক্ষ কাজও করি bind()যাতে সার্ভার পরবর্তীতে পুনরায় সংযোগ করতে পারে sendto() যদি এটি কোনো কারণে বন্ধ হয়ে যায়।

সার্ভারকে ক্লায়েন্টের সংযোগ সম্পর্কে অবহিত করা হয় যখন ক্লায়েন্ট Firebase-এ সার্ভার পোর্ট তথ্যের অধীনে তার SDP অফারটি লেখে, এবং সার্ভার সেখানে তার প্রতিক্রিয়া দিয়ে প্রতিক্রিয়া জানায়।

নীচের চিত্রটি একটি সকেট স্কিমের জন্য বার্তা প্রবাহের একটি উদাহরণ এবং ক্লায়েন্ট থেকে সার্ভারে প্রথম বার্তা প্রেরণের উদাহরণ দেখায়:

ক্লায়েন্ট এবং সার্ভারের মধ্যে সংযোগ পর্বের সম্পূর্ণ চিত্র

উপসংহার

আপনি যদি এই পর্যন্ত পড়ে থাকেন, তাহলে আপনি সম্ভবত তত্ত্বটি কর্মে দেখতে আগ্রহী। গেমটি খেলা যাবে teeworlds.leaningtech.com, এটা চেষ্টা করুন!

সহকর্মীদের মধ্যে প্রীতি ম্যাচ

নেটওয়ার্ক লাইব্রেরি কোড বিনামূল্যে পাওয়া যায় গিটহাব. আমাদের চ্যানেলে কথোপকথনে যোগ দিন Gitter!

উত্স: www.habr.com