Волей судьбы разрабатывал почти такой же сервер , правда с несколько более сложной обработкой пакетов. Примеры из MSDN смотреть нужно смотреть с большой осторожностью — ИМХО слишком много в них ошибок.
Прочитав обсуждение могу посоветовать внимательнее выбирать модель самого клинет-серверного взаимодействия, и, если есть возможность отдавать предпочтения простым моделям. Сделать так, чтобы сервер держал одновременно 100 подключений достаточно сложно (особенно если среди них присутсвуют соединения по комутируемым линиям).
Если Вы решитесь писать такой сервер рекомендую уделить внимание следующим вопросам:
— синхронизация потоков (если плохо спроектировать будут большие проблемы при отладке)
— система обработки ошибок — рекомендую написать эту систему с самого начала — потом внедрять будет очень сложно — а система жизненно важная. Рекомендую реализовать логи со стеками вызовов и т.п. Иначе фиг разберешься когда и где возникла ошибка.
— производительность потока, принимающего соединения — этот поток не должен содержать длительных операций (создание нити относительно длинная операция, а дисковый обмен — тем более)
— управление работающими потоками — контроль выполнения, диагностика зависания, ошибок и т.п.
— управление соединениями (особенна важна диагностика "умерших" соединений)
— утечки памяти — как в вашем сервере так и в СУБД (!) — их быть не должно
— уничтожение процессов/потоков (никаких Terminate (!))
— закрытие соединений
— внимательно смотреть в сторону многопроцессорного сервера (рассинхронизация процессорных кэшей); сервера, поддерживающего Terminal Services (раздельные простроансва имен объектов ядра для различных сессий); машины с несколькими сетевыми картами (осбенно если используешь UDP).

Это те грабли, которые я смог вспомнить навскидку. Ну а самое главное — правильно спроектировать архитектуру.

Надеюсь, что Вы словите меньше глюков, чем словил в свое время я.
С наилучшими пожеланиями Михаил Копачев.