जब आप Chess साइट Lichess.org पर एक चाल चलते हैं, तब क्या होता है

• Lichess दुनिया भर में लाखों खिलाड़ियों वाला एक मुफ़्त open source chess platform है
• Chrome DevTools के Network टैब का उपयोग करके client और server के बीच communication को मॉनिटर किया जा सकता है

WebSocket कनेक्शन

• सबसे पहला उल्लेखनीय network behavior एक ऐसे URL पर WebSocket कनेक्शन है, जो कुछ इस तरह दिखता है:

wss://socket2.lichess.org/play/H5uHz0egyvIA/v6?sri=bt6QzcyOiZg5&v=0  

• wss protocol, TLS का उपयोग करने वाले encrypted WebSocket connection को दर्शाता है
• WebSocket full-duplex communication की अनुमति देता है, जिससे बार-बार HTTP requests किए बिना client और server के बीच real-time updates संभव होते हैं

लोकल खिलाड़ी की बारी

• जब आप कोई action करते हैं, तो data packet का आदान-प्रदान होता है:

// 22:51:35.280 पर भेजा गया  
{  
  "t": "move",   
  "d": {  
    "u": "d2d4",  
    "l": 32,  
    "a": 1  
  }  
}  

• server से प्राप्त message:

// 22:51:35.312 पर प्राप्त हुआ  
{  
  "t": "ack",  
  "d": 1  
}  

• यह बताता है कि server ने हमारी action प्राप्त कर ली है

// 22:51:35.312 पर प्राप्त हुआ  
{  
  "t": "move",  
  "v": 1,  
  "d": {  
    "uci": "d2d4",  
    "san": "d4",  
    "fen": "rnbqkbnr/pppppppp/8/8/3P4/8/PPP1PPPP/RNBQKBNR",  
    "ply": 1,  
    "clock": {  
      "white": 300,  
      "black": 300  
    }  
  }  
}  

• यह message हमारी चली गई चाल और updated game state के बारे में विस्तृत जानकारी देता है

प्रतिद्वंद्वी की बारी

• जब प्रतिद्वंद्वी कोई action करता है, तो server से ऐसा ही packet प्राप्त होता है:

// 22:51:43.489 पर प्राप्त हुआ  
{   
  "t": "move",  
  "v": 2,  
  "d": {  
    "uci": "d7d5",  
    "san": "d5",  
    "fen": "rnbqkbnr/ppp1pppp/8/3p4/3P4/8/PPP1PPPP/RNBQKBNR",  
    "ply": 2,  
    "dests": {  
      "c2": "c3c4",  
      "g2": "g3g4"  
      // अतिरिक्त संभावित चालें  
    },  
    "clock": {   
      "white": 300,  
      "black": 300  
    }  
  }  
}   

• dests parameter मौजूदा position से उपलब्ध सभी चालों की सूची देता है

Lichess का architecture

• Lichess का real-time play system मुख्य रूप से दो प्रमुख services से बना है (दोनों Scala में लिखी गई हैं):
  1. lila: core service, जो game logic, state, user interaction आदि जैसी मुख्य functionality को संभालती है
  2. lila-ws: WebSocket handling में विशेषज्ञ service, जो client और lila के बीच bridge की भूमिका निभाती है

architecture overview

lila <-> redis <-> lila-ws <-> websocket <-> client  

• lila Redis के माध्यम से lila-ws के साथ communicate करता है, और lila-ws client के साथ WebSocket connections को manage करता है

Redis Pub/Sub के साथ communication

• move events को Redis Pub/Sub channel पर publish किया जाता है, जिसे lila subscribe करके moves को process करता है
• Redis Pub/Sub at-most-once delivery देता है। इसमें message loss संभव है, लेकिन memory usage कम होता है

MongoDB के साथ अंतिम data persistence

• lila game state को MongoDB में store करता है, लेकिन हर single move को तुरंत save नहीं करता
• इसके बजाय, यह moves को buffer करता है और समय-समय पर save करता है ताकि DB load कम हो
• कोई महत्वपूर्ण event होने पर game state को flush किया जाता है

चल रहे game में शामिल होना

• जब कोई player connect करता है, तो वह v parameter देता है ताकि system को यह पता रहे कि उसे game का कौन-सा latest version मालूम है
• lila-ws ConcurrentHashMap का उपयोग करके चल रहे games के सभी events को track और manage करता है

समापन

Lichess में एक चाल चलने की प्रक्रिया का सार इस प्रकार है:

1. client, lila-ws के साथ WebSocket connection स्थापित करता है
2. player के action करने पर client, lila-ws को move event भेजता है
3. lila-ws move प्राप्त होने की पुष्टि करते हुए ack response भेजता है
4. move event Redis Pub/Sub channel पर publish होता है और lila उसे process करता है
5. lila move प्राप्त करके game state update करता है और अंततः उसे MongoDB में save करता है। updated game state फिर lila-ws के माध्यम से client को वापस भेजी जाती है
6. client updated game state प्राप्त करता है, जो नई चाल और game state में हुए बदलावों को दर्शाती है

GN⁺ की राय

• यह पोस्ट लोकप्रिय open source chess platform lichess.org के real-time gameplay को संभव बनाने वाली backend architecture और process पर विस्तार से नज़र डालती है
• यह real-time web applications बनाते समय ध्यान में रखने वाले प्रमुख तकनीकी तत्वों का परिचय कराती है, जैसे WebSocket के साथ real-time communication, Redis Pub/Sub के जरिए scalable message delivery, और MongoDB में अंतिम data storage
• Lichess का architecture real-time multiplayer games के लिए बहुत उपयुक्त है, लेकिन यही patterns और technologies chat, collaboration tools, social media feeds जैसी दूसरी real-time web apps पर भी लागू किए जा सकते हैं
• real-time features user experience और interaction को बेहतर बना सकते हैं, लेकिन वे scalability, reliability और data consistency जैसी विशिष्ट तकनीकी चुनौतियाँ भी लाते हैं। यह पोस्ट इन चुनौतियों से निपटने की रणनीतियाँ प्रस्तुत करती है
• इसी तरह के tech stack का उपयोग करने वाले open source projects में Socket.IO (Node.js-आधारित real-time application framework) और RethinkDB (real-time web apps के लिए optimized NoSQL database) शामिल हैं
• इस पोस्ट का analysis, Lichess के source code की प्रत्यक्ष समीक्षा पर आधारित नहीं है, इसलिए वास्तविक implementation में अंतर हो सकता है। फिर भी, बताए गए मूल concepts और architectural patterns अब भी मान्य हैं
• real-time systems डिज़ाइन करते समय यह सावधानी से विचार करना चाहिए कि at-most-once (message loss की संभावना) और at-least-once (message duplication की संभावना) delivery में से कौन-सा विकल्प अधिक उपयुक्त है। यह application की requirements और trade-offs पर निर्भर करता है

[GN⁺]

Hacker News राय

• Chess.com की time structure को लेकर शिकायत है। लगता है सर्वर समय को track करता है और transmission time व latency को नज़रअंदाज़ करता है। मोबाइल client पर time-limited game खेलते समय यह खास तौर पर असुविधाजनक है

  • यह network code की समस्या भी हो सकती है, और puzzles में अक्सर त्रुटियाँ होती हैं
  • Chess.com की technology कुछ कच्ची लगती है

• Lichess ने StackOverflow वाला approach चुना है और शक्तिशाली servers का उपयोग करता है

  • यह game state को समय-समय पर save करता है, लेकिन कहाँ save करता है यह स्पष्ट नहीं है
  • प्रति game लागत बहुत कम है: $0.00027, यानी 3,671 games पर 1 डॉलर
  • एक ही data center पर निर्भरता के कारण कभी 10 घंटे का outage हुआ था

• server side पर moves की गणना करना consistency सुनिश्चित करता है, और सीमित processing power या energy वाले clients के performance को optimize करता है

  • यह नए platforms पर open source software clients को implement करने की बाधा कम करने के लिए भी हो सकता है
  • chess rules को implement करना झंझट भरा हो सकता है, और Lichess में भी कभी logic bug था

• Redis pub/sub channel में message loss ko kaise handle kiya jata hai, इस पर पर्याप्त विवरण नहीं है

• "l" parameter शायद server पर देखी गई latency को दर्शाता है

• यह आश्चर्यजनक है कि server सभी legal next moves को enumerate करके भेजता है

  • यह सीमित clients के लिए फायदेमंद हो सकता है, लेकिन यह client side पर calculate करने से सस्ता है या नहीं, इस पर संदेह है

• websocket server को protect करने के तरीके पर सवाल है

  • Cloudflare के free plan का उपयोग करने पर latency बढ़ती है
  • free solution को लेकर जिज्ञासा है

• यह जिज्ञासा है कि protocol को ack की ज़रूरत क्यों है

  • TLS से wrapped websocket message integrity सुनिश्चित कर सकता है

• FEN सिर्फ board state को encode करता है, game state को शामिल नहीं करता

  • Scala में लिखा गया scalachess project सफलतापूर्वक maintain हो रहा है