Როგორ არის მოწყობილი რეალურ დროში ცოცხალი დილერების ნაკადი

1) რატომ გვჭირდება „რეალური“ რეალობა?

Live-კაზინო არის ვიდეო დოკუმენტაციისა და გარიგების ლოგიკის ერთობლიობა. მთელი ღირებულება სინქრონიზაციაშია: მოთამაშე ხედავს დილერს, დააჭერს „დაყენებას“, ზურგჩანთას აფიქსირებს ფსონს „No more bets“ - ზე, ხოლო შედეგი გამოითვლება გამჭვირვალედ. ნებისმიერი რასინქრონიზაცია (ვიდეოს შეფერხება, „გვიან“ ფსონი) გარდაიქმნება VOID- ში, დავაში ან ნდობის დაკარგვაში.

2) კონტური სტუდიიდან მოთამაშემდე

სტუდია - Ingest - მიწოდების ორკესტრი - Pleer

1. სტუდია: კამერები 1080p/60 (ან 4K/60), მიკროფონები, შუქი, მიქსერი, keyer overley (ტაიმერები/მინიშნებები).

2. Ingest: SDI/NDI - encoder (h. 264/h. 265, Opus/AAC) - SRT/RTMP მისაღებად.

3. დამუშავება: ოვერლეიტების კომპოზიცია, არქივის ჩანაწერი, CV/RFID მოვლენები, სინქრონიზაცია timecode- ზე.

4. ტრანსკოდი: პროფილები ქსელისთვის/მოწყობილობებისთვის (1080p/720p/480p), GOP 0. 5-1 გვ.

5. ბიულეტენი:

WebRTC - მთავარი დაბალი სიჩქარის ტრაქტი (p95 150-500 ms), LL-HLS/DASH - ხალხური (2-5 ს), DataChannel/WebSocket - განაკვეთების/ტაიმერების სიგნალები.
6. პლეიერი: სინქრონიზებულია დროის სერვერთან (UTC), ასახავს ტაიმერებს და იღებს გადაწყვეტილებებს.

3) ოქმები: სად არის სათანადო

WebRTC: ბრაუზერის/მობილური, UDP, საკონსულტაციო კონტროლი, ორმხრივი DataChannel.

SRT: სტაბილური ingest სტუდიიდან (ARQ, დაშიფვრა), კარგია ჯიტერის/ზარალის წინააღმდეგ head-end- მდე.

LL-HLS/DASH: მასობრივი ფოლკლორული/CTV, სეგმენტები 1-2 ს, ხშირი ნაწილობრივი განახლებები; შეფერხება უფრო მაღალია, მაგრამ მასშტაბი იაფია.

RTMP: მხოლოდ როგორც „გასული საუკუნე“ თავსებადობისთვის (ingest), არა როგორც კლიენტის მიწოდება.

4) რაუნდებისა და ფსონების სინქრონიზაცია

ჭეშმარიტება სერვერის დროა. კლიენტი პერიოდულად სინქრონიზირებულია (NTP მსგავსი პინგები) და ასწორებს ადგილობრივ ოფსეტს.

სასიცოცხლო ციკლი:

1. `round. ღია "- გააქტიურებულია განაკვეთების ფანჯარა (მაგ. 15 გვ.).

2. `round. close '- სერვერი წყვეტს განაკვეთების მიღებას, UI ბლოკირდება.

3. `round. Result '- შედეგი CV/RFID/ოპერატორისგან.

4. `round. settle '- გადახდა/ჩამოწერა საფულეში.

ინვარიანტები: სერვერის ვადა „უფრო მკაცრია“ კლიენტისთვის. თუ ქსელი იშლება, უმჯობესია უარი თქვან განაკვეთზე, ვიდრე მიიღოთ „გონგის შემდეგ“.

5) მონაცემთა არხები და API

სიგნალები (რეალი დრო): DataChannel/WebSocket - მაგიდის სტატუსები, ტაიმერები, განაკვეთების დადასტურება.

გარიგებები (ფულადი): REST/gRPC იდემპოტენტურობით ('X-Idempotency-Key') და HMAC ხელმოწერით.

Telemetria QoS: RTT, packet loss, bitrate, dropped frames, latency 'bet. accept`.

მაგალითი 'round. close`:

json
{
"event": "round. close",  "tableId": "evo_blackjack_23",  "roundId": "R-2025-10-17T14:23:10Z-evo-23",  "ts": "2025-10-17T14:23:12. 000Z",  "serverTime": "2025-10-17T14:23:12. 000Z"
}

განაკვეთის განლაგების მაგალითი (იდემპოტენტურად):

http
POST /live/bet/place
X-Idempotency-Key: 9a7f-2b1c
Content-Type: application/json
{
"playerId":"p_123",  "tableId":"evo_blackjack_23",  "roundId":"R-2025-10-17T14:23:10Z-evo-23",  "selections":[{"market":"player","amount":"10. 00"}],  "currency":"EUR"
}

6) ტაიმინგი და შეფერხებების ბიუჯეტები (მიზნები)

დაწკაპეთ 'hold' საფულეში: p95-150-250 ms.

`round. close '- ტექნიკის გაჩერება: 50 ms ევრო სერვერზე + მყისიერი UI დაბლოკვა.

'result' '' settle ': p95-1-2 წმ (CV/RFID შემოწმების ჩათვლით).

ვიდეო შეფერხება: WebRTC p95-500 ms; LL-HLS ≤ 5 с.

სიგნალები: მონაცემთა არხი p95-150 ms რეგიონში.

7) მასშტაბები და edge არქიტექტურა

Edge-SFU/WebRTC კვანძები რეგიონების მიხედვით (EU/UK/CA/LA/SEA) უფრო ახლოს არის მოთამაშესთან.

Geo-routing (Anycast/DNS) და ჯანმრთელობის ტესტები QoS (RTT/PLR) მიხედვით.

აბონენტების რაოდენობის, ბიტრისა და დეგრადაციის სიგნალების აუტოსალინგი.

Origin shield for LL-HLS (პირას პლეილისტების/სეგმენტების ქეში).

პროფილების პულები: ქსელის (UDP ოპტიმიზირებული), CPU-heavy (ტრანსსკოდი), მემორიალური-ჰევი (ბუფერიზაცია).

8) ვიდეო სიგნალის და ოვერლეების დამუშავება

ოვერლი სერვერზე (კომპოზიცია): ყოველთვის ემთხვევა ვიდეოს, მაგრამ უფრო ძვირია, ვიდრე ტრანსკოდი.

ოვერლი კლიენტზე (HTML/CSS/Canvas): იაფი, მოქნილი; კრიტიკულია იგივე დროის სერვერი და მოვლენების მარკერები.

რეკომენდაცია: ტაიმერები/“ No more bets“ - როგორც აურზაური კლიენტზე, მაგრამ უკანა პლანზე„ მკაცრი “სერვერის ვადა.

9) ხარისხი (QoS) და დაკვირვება

ეს-SLO: WebRTC RTT, packet loss, bitrate, server-client დროის სხვაობა, rate 'bet. reject`, `VOID/REFUND`.

Business SLO: სესიის გამართვა, საჩივრები, CR ლობი და თამაში.

Dashboards: end-end trace ('traceId': player - API - საფულე, პროვაიდერი, ვებჰუკი), QoS ბარათები გეო/სატელეკომუნიკაციო ოპერატორებისთვის.

ალერტები: „VOID“ - ის ზრდა, RTT> 300 ms ზრდა, packet loss> 5%, ზრდა 'bet. reject` > 0. 2%.

10) უსაფრთხოება და პატიოსნება

mTLS სერვისებსა და პროვაიდერებს შორის, HMAC ვებჰუკებზე.

Anti-replay: `X-Request-Timestamp/Nonce`, окно ±300 с.

Idempotention on 'bet. Place ',' payout. ', PSP ვებჰუკები.

რაუნდის გულწრფელობა: სტუდიური ვიდეოს ჩაწერა, ეტიკეტები CV/RFID და დილერის დაჭერა WORM საცავში აუდიტის/დავის მიზნით.

CSP/Referrer-Policy მფრინავ დომენებზე; წვდომის ნიშნები მოკლე TTL.

11) CV/RFID და „ჭეშმარიტების წყარო“

RFID: ჩიპები/უჯრედები/განაკვეთების ველები.

CV: ბარათების/ბურთების ამოცნობა, დილერის ხელების ტრეკინგი.

Elections: თუ სენსორი კამათობს CV- სთან, ის პრიორიტეტია პოლიტიკაში (ჩვეულებრივ, RFID - CV - ხელით შეყვანა), ყველა გადაწყვეტილება - ჟურნალში.

12) ფოლბეკი და დეგრადაცია

WebRTC- მა LL-HLS- ზე დეგრადაცია მოახდინა, UI წინასწარ ამცირებს განაკვეთების ფანჯარას (მაგალითად, 1-2 წმ-ით).

CV/RFID მიუწვდომელია; სახელმძღვანელო შეყვანა ორმაგი შემოწმებით; ეჭვქვეშ - VOID.

Edge კვანძი გადატვირთულია DNS/Anycast- ის მყისიერი რევალანსით; ფასიანი მაგიდების/რეგიონების პრიორიტეტი.

13) შესაბამისობა და RG

Geo-fencing: ქვეყნის მასშტაბით მაგიდების/პროვაიდერების ხელმისაწვდომობა.

იურიდიული/ასაკობრივი ოვერლეები ლოკალურ ენაზე.

RG პოლიტიკა: რბილი მინიშნებები/დრო, რისკის შაბლონებით; განაკვეთების/სესიების ლიმიტები.

PII იზოლაცია: პლეერი არ გადასცემს PII- ს, მხოლოდ ფსევდონიმებს „playerID“.

14) DR/HA: შავი ეკრანის უფლების გარეშე

Multi-AZ სტუდია ან სარეზერვო ადგილი; ენკოდერის/ქსელების დუბლირება.

რაუნდის სიგნალების ორმაგი ჩაწერა (ორკესტრი/CV) დამოუკიდებელ თაროებში.

VOID/REFUND გეგმა კომუნიკაციისა და ტაიმინგის შაბლონებით.

რეგულარული წვრთნები: AZ გამორთვა, ქსელის დეგრადაცია, CV- ის დაკარგვა.

15) ანტი შაბლონები

დაეყრდნო კლასიკურ დროს, როგორც ჭეშმარიტებას.

არ არსებობს LL-HLS ფოლკლორი - „შავი ეკრანი“ WebRTC- ს პრობლემებით.

განათავსეთ ნაკადის ანალიტიკა OLTP- ში საფულე - ლატენტობის ვარდნა და 'reect _ rate'.

Idempotence და HMAC- ის არარსებობა ფულზე/ვებჰუკებზე.

„მშვიდი“ ასეტების/ოვერლეულების შეცვლა ვერსიის გარეშე (გატეხილი მომხმარებლები).

ნულოვანი ლიმიტები DataChannel/WebSocket (ფლეშ/DoS ჩატი).

WORM არქივის ნაკლებობა: პატიოსნების დასამტკიცებლად არაფერი აქვს.

16) ცოცხალი ნაკადის გაშვების ჩეკის სია

სტუდია/ingest

კამერები/encoders, UPS; დაშიფრული SRT ingest.
კალიბრანები CV/RFID, დილერის პედლები სინქრონიზებულია.

მედია

WebRTC p95-500 ms, LL-HLS განლაგებულია (სეგმენტი 2 c, preload hints).
პროფილები 1080/720/480, GOP-1 c, აუდიო Opus/AAC.

სინქრონიზაცია/თამაში

სერვერის დრო კლიენტზე, ვადა 'round. close 'შემოწმებულია.
ტაიმერები - როგორც კლიენტის შეხედულებისამებრ + „მკაცრი“ სერვერის გაჩერება.

ფინანსები/უსაფრთხოება

ფულის/ვებჰუკების იდენტიფიკაცია, HMAC + mTLS, anti-replay.
მრგვალი და ვიდეო ჟურნალი WORM- ში; PITR საფულე.

დაკვირვება

QoS დაშბორდები (RTT/PLR/bitrate), 'bet. reject`, `VOID`, `settle p95`.
ალერტები დროების დეგრადაციისა და დრიფტისთვის.

DR/ოპერაციები

სარეზერვო სტუდია/არხი, ფოლკლორული სკრიპტები და VOID/REFUND.
Runbooks, საკომუნიკაციო შაბლონები, რეგულარული სწავლებები.

დილერების ნამდვილი ცოცხალი ნაკადი არის ზუსტად სინქრონიზებული მედია ხაზი და ფულადი ძრავა. WebRTC უზრუნველყოფს სიჩქარეს, LL-HLS - სტაბილური ფოლკლორული, SRT - საიმედო ingest; მონაცემთა არხები გადასცემენ კრიტიკულ სიგნალებს, ხოლო სერვერის დრო ცემენტირებს რაუნდის პატიოსნებას. დაამატეთ ტელემეტრია QoS, idempotent ფული, უსაფრთხოება და DR - და მოთამაშე დაინახავს ბუნებრივ, სწრაფ და სამართლიან თამაშს, ხოლო ოპერატორი მიიღებს პროგნოზირებულ SLO და ზღვარს.