Постановка проблеми
теоритическая частина
У сокетах Берклі, які працюють з TCP протоколом є API connect / accept, щоб виконати тристоронню рукостискання, і потім в прихованому від програміста режимі організувати потік, з контролем доставки і цілісності даних. Проблема в тому, що conntect / accept це блокуючий виклик, і не можна підключиться до декількох портів одночасно (одним сокетом), щоб цього не робити і знизити навантаження на обчислювальний пристрій (підтримка великої кількості коннектов) придумали клієнт-серверну архітектуру, в якій сервер буде агрегувати весь трафік надсилається на нього різними клієнтами і підтримувати ті самі множинні з'єднання.
Є два рішення проблеми підтримки множинних connect / accept для серверів - це мультіпоточность і використання неблокірующіх сокетов. Я буду розглядати перший випадок, тому що це мені ближче.
проектування
Тут же вирішення проблеми доступу до ресурсів повністю належить на плечі використовуваної бібліотеки, залишається тільки прописати логіку обробки отриманих даних.
Як я робив це
Для того, щоб написати TCPConnectionHandler, спочатку необхідно написати ThreadPool, який би мав можливість створення і переривання потоків (і поділ потоків на тих, які знаходяться в стані завершення, і тих, які знаходяться в роботі).
А TCPConnectionHandler дивився б якісь із з'єднань завершилися, відповідав за broadcast / multicast розсилки до підключеним сокетів, та зберігання / знищення призначених для користувача даних, якими володіє сокет.
Структура призначених для користувача даних сокета досить проста - це нік і чатрум. в якому знаходиться даний користувач. Звідси випливає простота використання такого механізму, щоб створити кімнату, потрібно просто перейти в неї.
Мікро-Адаменко
Адміністрування серверів, які підтримують тільки відкритий коннект (без шифрування) взагалі має заслуговувати окремої статті про те, як можна побудувати стійку систему одноразових паролів і хеш-команд, але опустимо все це. Я просто використав можливість введення текстового ключа, і команди за ним, для виконання (Якщо довжина ключа буде досить велика кілька мегабайт, то можна убезпечити себе від брутфорса), але важко убезпечити себе від перехоплення цього самого ключа =). Але, теоретично, схема виглядає так:
- Сервер генерує challenge число або набір байт.
- Клієнт хешірует одноразовим ключем challenge + комманду і отруює хеш і комманду у відкритому вигляді.
- Сервер повторно хешірует команду з challenge і порівнює результат хешу з отриманим.
- Якщо хеш валідний то комманда виконується.
приклади команд
Вікно вітання з маленьким help.
Приховані можливості текстового чату
1. Обмін даними по хеш-чатрумам
Наприклад не один нормальний користувач не буде сидіти в чатруме з назвою PbgkkCzrM8VToEgcDcCSfQdw5p1IaoRHiBu5d21XGv92c0fKmJUo3XoxFqtdN5tOzmRY5PrSQti6uKFOZTatQQ ==
А ось боти цілком. І міняти ці кімнати через деякий время.2. Прозоре шифрування в текстовому поданні Base64.
Ми всі вже звикли до автоматичного шифрування даних, а як буде ностальгічно слати дані співрозмовникам, які були зашифровані з pre-shared-key.3. Анонімність, прив'язана тільки до пари ip: port (привіт tor, i2p), і ідентифікація / аутентифікація з співрозмовниками в межах підтримуваної сесії. 4. легковаге даних.
Ніякого додаткового payload для підтримки сесії, або передачі контенту. Тільки текстовий контент.5. Простий клієнт (nc, putty, etc) 6. легковаге і продуктивність сервера
На моєму маці використовувана бібліотека і клієнт скомпільовані без оптимізацій важать 156 + 40 = 196 Кб. Тобто можливість запускати на старих пристроях, з малою кількістю оперативної пам'яті, і мінімальною підтримкою POSIX.7. OpenSource - відкритість, і нічого зайвого. + Можливість внести свої власні доробки, як шифрування, ідентифікацію,
аутентифікацію, передачу файлів і т.д.
GitHub, але тримайте сильно-вразливих подалі від монітора.
CMake, дозволяє зібрати під свою платформу і запустити на локальному хості, mac / linux (+ windows in future з вашою допомогою).
Допилювання фич на вимогу.