Сергей Протько

1. Отрисовку точно стоит вынести в отдельный от чтения данных поток

2. По поводу бесконечного цикла - именно так. При вызове recvfrom у вас будет блокирован ваш поток пока не придут данные, так что ничего страшного от использования бесконечного цикла у вас не будет. Именно по этому и нужно выносить это все дело в отдельный процесс/поток.

3. Кросплатформенная разработка в вижле? Увы нет, во всяком случае насколько я знаю. Почитайте про cmake и просто make (cmake плохо дружит с вижлой, иногда бывают проблемы и после генерации проекта приходится тратить время еще на настройку, так что чаще проще уж один раз настроить и таскать с собой настройки проекта).
Вообще тут проще побродить по опенсорсным проектам кросплатформенным и посмотреть как там все это дело реализованно.

3.5. ну тут все просто. в linux POSIX, в windows - WinApi (или WinRT если вам хватит поддержки win8+). То есть скажем... код сервера работающий с сокетами у вас под эти две платформы будет различаться на 90% так как все завязано на системное api. То есть вам нужно сделать какую-то прослойку инкапсулирующую сетевую часть, и уже ее реализацию подменять при сборке под конкретную платформу. Либо взять готовое решение для этой прослойки. А вот при реализации бизнес-логики различия между платформами зависят только от самой логики.

вообще никаких ограничений по форматам данных, с которыми вы работаете нету. От расширения файла внутренняя структура файла не изменится. Проще всего для подобного использовать csv.

если на низком уровне то все просто. Главный процесс слушает сокет и делает accept. Затем есть 2 варианта: мультиплексировать запросы (из массива выбирать сокеты готовые для чтения через select/epoll и делать recv или accept в зависимости от того что за сокет готов предоставить данные) либо запихнуть обработку сокета в отедельный поток/процесс. Процессы надежнее ибо если он упадет то серверу от этого ничего не сделается.

А далее уже идут оптимизации. Тот же nginx использует мультиплексирование внутри процессов-воркеров. Мультиплексирование позволяет более грамотно подойти к использованию ресурсов внутри одного процесса, а несколько процессов позволяют обрабатывать паралельно больше запросов. В то же время обработка этих запросов никак не затрагивает главный процесс слушающий сокет на предмет новых подключений.

По поводу самих воркеров. Так как форк нового процесса все же операция не такая уж и дешевая, имеет место такая практика как префорк. То есть в памяти уже крутится какое-то число готовых процессов и при появлении запросов на обработку они просто передаются туда. При повышении количества запросов увеличивается количество воркеров, что минимизирует потери от блокировки процессов...

вообще погуглите про проблему 10k, можно нагуглить кучу алгоритмов обработки запросов.

А что касается lighttpd то в документации описаны случаи когда нужно использовать многопроцессорность, и приведены возможные проблемы с модулями. Именно советов "не использовать" там нету.