mitrm: сайтами не занимаюсь, использую для всяких опытов с линуксом и сокетами. было раз, когда отключил пинги, стало жууутко тормозить, видимо гипервизор их периодически пингует и если не отвечает, ставит минимальный приоритет.
Радует пинг в 5мс. Еще из недорогих - arubacloud, 1 евро за неплохой конфиг в 1гб памяти и 20гб диска
что конкретно нужно-то? если обычный юниксовый таймстамп, это ж просто количество секунд. поделить на (60*24) и получите "уникальный идентификатор дня", который в итоге отсортировать тем же qsort. вот и будет у вас сверхбыстрое распределение по дням
beduin01: драйвер и контролирует. где-то хранится контекст запроса, где указано, сколько уже прочитано. как только поступает новая порция данных от устройства, контекст обновляется.
так и сидит себе драйвер. получил запрос на чтение - разослал команды устройствам "читай вот такие-вот блоки", получил блоки данных - обновил контексты, все данные пришли - сообщил программе, что чтение завершено. ну и так далее. всё это, в основном, строится на очередях, списках и семафорах. пока данных нет и очереди пусты, процесс драйвера "спит". при добавлении нового запроса или ответа в очередь, драйвер просыпается и начинает обрабатывать данные. много потоков не требуется
Максим Резванов: это уже ваше дело как создавать такую штуку.
я тоже пытаюсь нечто похожее создать, только всё некогда.
например, на сервере завести список "открытых чатов", у каждого чата свой IDC, в чате N человек с своими идентификаторами IDU, клиенты шлют серверу пакеты с открытым заголовком, в котором будет ID чата и шифрованное сообщение (ключ общий на весь чат, сервер его не знает). как только сервер получает сообщение, оно рассылается всем участникам IDU чата IDC, потом каждый клиент расшифровывает сообщение и в случае успеха показывает его на экране. можно добавить временные метки, можно дополнительные фичи... всё на усмотрение разработчика. у себя я хочу сделать, к примеру, полноценный собственный протокол транспортного уровня на замену TCP
Максим Резванов: да что вы подразумеваете под соединением людей? проброс сообщений через сервер? (зависит от реализации, я б через очереди и UID сделал) поиск друг друга? (рандом же)
если "безопасно", то взаимодействие через сервер - иначе видно, на какой IP пойдут сообщения.
клиент подключается к серверу, ему назначается уникальный ID, потом из списка подключенных ID случайным образом выбирается свободный, который тоже "в поиске", генерируется ключ шифрования по Диффи-Хеллману, чтоб сервер не знал, о чем общение ведется, ну и сервер перекидывает туда-сюда шифротекст между клиентами.
beduin01: асинхронное чтение файла? Посмотрите документацию к функции ReadFileEx. одним вызовом запускается выполнение действия, далее можно проверять состояние запроса, выполнилось чтение или ещё нет.
обработка без создания нового потока? представьте сервис, обрабатывающий поступающие запросы по очереди. тогда запросом на чтение файла мы лишь помещаем в эту очередь новый запрос.
к примеру, я делал однопоточный HTTP прокси-сервер, при этом к нему могли подключаться сотни клиентов одновременно. создавать новый поток на каждую мелочь не нужно, это потребляет ресурсы на переключение контекста
регистрация по никнеймам + кнопка "добавить контакт" с поиском по нику? UID как в аське или Tox?
или же у вас проблема именно создания соединения между конкретными пользователями без участия сервера? могут быть проблемы с NAT, гуглите UDP (есть и TCP) hole punching
