TrackFox: литиевый аккум можно и за минуту убить, разрядив в ноль через КЗ.
В ноутбуках года за 3-4 деградируют до смерти. Сейчас посмотрел на своём (брал в 2012), износ 17%, но это его постоянно в режиме сохранения аккумулятора держал
Григорий: если он не отформатирован, как локальный диск он не появится - зайдите в "Диспетчер устройств" и нажмите "Обновить конфигурацию", затем перейдите в "Диспетчер дисков" imghst.co/39/dd.png
mitrm: сайтами не занимаюсь, использую для всяких опытов с линуксом и сокетами. было раз, когда отключил пинги, стало жууутко тормозить, видимо гипервизор их периодически пингует и если не отвечает, ставит минимальный приоритет.
Радует пинг в 5мс. Еще из недорогих - arubacloud, 1 евро за неплохой конфиг в 1гб памяти и 20гб диска
что конкретно нужно-то? если обычный юниксовый таймстамп, это ж просто количество секунд. поделить на (60*24) и получите "уникальный идентификатор дня", который в итоге отсортировать тем же qsort. вот и будет у вас сверхбыстрое распределение по дням
beduin01: драйвер и контролирует. где-то хранится контекст запроса, где указано, сколько уже прочитано. как только поступает новая порция данных от устройства, контекст обновляется.
так и сидит себе драйвер. получил запрос на чтение - разослал команды устройствам "читай вот такие-вот блоки", получил блоки данных - обновил контексты, все данные пришли - сообщил программе, что чтение завершено. ну и так далее. всё это, в основном, строится на очередях, списках и семафорах. пока данных нет и очереди пусты, процесс драйвера "спит". при добавлении нового запроса или ответа в очередь, драйвер просыпается и начинает обрабатывать данные. много потоков не требуется
Максим Резванов: это уже ваше дело как создавать такую штуку.
я тоже пытаюсь нечто похожее создать, только всё некогда.
например, на сервере завести список "открытых чатов", у каждого чата свой IDC, в чате N человек с своими идентификаторами IDU, клиенты шлют серверу пакеты с открытым заголовком, в котором будет ID чата и шифрованное сообщение (ключ общий на весь чат, сервер его не знает). как только сервер получает сообщение, оно рассылается всем участникам IDU чата IDC, потом каждый клиент расшифровывает сообщение и в случае успеха показывает его на экране. можно добавить временные метки, можно дополнительные фичи... всё на усмотрение разработчика. у себя я хочу сделать, к примеру, полноценный собственный протокол транспортного уровня на замену TCP
Максим Резванов: да что вы подразумеваете под соединением людей? проброс сообщений через сервер? (зависит от реализации, я б через очереди и UID сделал) поиск друг друга? (рандом же)
если "безопасно", то взаимодействие через сервер - иначе видно, на какой IP пойдут сообщения.
клиент подключается к серверу, ему назначается уникальный ID, потом из списка подключенных ID случайным образом выбирается свободный, который тоже "в поиске", генерируется ключ шифрования по Диффи-Хеллману, чтоб сервер не знал, о чем общение ведется, ну и сервер перекидывает туда-сюда шифротекст между клиентами.
