Coding contest-এর online judge ডিজাইন

লক্ষ্য: user কোড জমা দেয়; সিস্টেম লুকানো test case-এর বিরুদ্ধে চালিয়ে দ্রুত verdict (Accepted, Wrong Answer, Time Limit ইত্যাদি) ফেরত দেয়।

Requirement

অনেক ভাষা সমর্থন।
অবিশ্বস্ত কোড নিরাপদে চালানো।
সময় ও memory সীমা কার্যকর করা।
Contest spike সামলানো, যখন হাজারো মানুষ একসাথে জমা দেয়।
ফল ও ranked leaderboard দেখানো।

Architecture

API server: submission নেয়, সংরক্ষণ করে, ID ফেরত দেয়।
Queue: অপেক্ষমাণ submission রাখে।
Judge worker: submission নিয়ে sandbox-এ চালায় ও verdict রেকর্ড করে।
Database: problem, test case, submission, ফল।
Storage: test data object storage-এ, worker-এ cache করা।
ফল পৌঁছানো: client poll করে, অথবা WebSocket বা SSE-তে ফল পায়।

Queue কেন

Judging-এ কয়েক সেকেন্ড লাগে এবং সময় বদলায়। Queue spike মসৃণ করে, worker আলাদাভাবে scale করতে দেয় এবং worker মরলে retry সম্ভব করে। আলাদা queue বা অগ্রাধিকার রাখুন, যেমন practice-এর আগে contest submission।

Sandbox (সবচেয়ে গুরুত্বপূর্ণ)

User-এর কোড ফাইল পড়তে, network খুলতে, fork-bomb করতে বা অনন্তকাল চলতে চেষ্টা করতে পারে। আলাদা করে রাখুন:

ন্যূনতম filesystem-সহ container বা microVM।
CPU সময়, memory ও process সংখ্যা সীমিত করতে cgroups।
বিপজ্জনক system call আটকাতে seccomp / syscall filter।
Network নেই, এবং ছোট temporary folder ছাড়া read-only filesystem।
অনধিকারপ্রাপ্ত user হিসেবে চালান, প্রতিবারের পর পরিবেশ ধ্বংস করুন।
CPU সীমার পাশাপাশি wall-clock timeout।

এ কাজে isolate বা gVisor-এর মতো টুল আছে। জমা দেওয়া কোড কখনো সরাসরি host-এ চালাবেন না।

Judging প্রবাহ

(দরকার হলে) নিজস্ব সীমা দিয়ে compile।
প্রতিটি test case-এর জন্য input দিন, output ধরুন, সীমা কার্যকর করুন।
প্রত্যাশিত output-এর সাথে মেলান (হুবহু মিল, বা অনেক বৈধ উত্তরের problem-এ বিশেষ checker)।
প্রথম ব্যর্থতায় থামুন (বা scoring অনুযায়ী সব চালান) এবং verdict ফেরত দিন।

নির্ভুলতা ও ন্যায্যতা

সময় মাপা মেশিনের load অনুযায়ী বদলায়, তাই একই রকম নির্দিষ্ট worker-এ চালান এবং সীমানার কেস আবার চালান। Test data লুকিয়ে রাখুন যাতে user উত্তর hard-code করতে না পারে।