Есть некая складская программа стороннего разработчика со своей СУБД, некоторые выдержки логики работы серверной части:
При осуществлении записи одного клиента (DOS приложение) происходит оповещение всех остальных клиентов по списку о изменении в базе. Работа по Netbios через TCP/IP, разрешение - через WINS. Все четко работает до определенного момента. Если клиент завершил работу DOS программы некорректно (крестиком или выключение питания), то в списке серверного приложения все равно висит этот клиент для оповещения.
И тогда при осуществлении записи кого-либо при оповещении всех об изменении данных, эта серверная программа доходит до выключенного компьютера и виснет на несколько секунд. Т.е. для всех клиентов замирает.
Прошу не обсуждать логику работы программы - такая работа некорректна, это понятна. Если убрать WINS, так вообще все виснет в одном потоке...
Может кто подскажет, как системными средствами ускорить процесс прохождения оповещения выключенных компов в данной ситуации?

Добавлю, что по логике работы самой серверной части программы при таких оповещениях она не ждет отклика от ее приложения. Это по словам разработчика.
Т.е. отклик ждет сама система, в данном случае Windows Server

Разработчик ничего не переделывать не хочет.
Я то промониторю, но мне придется снимать коннекты вручную из списка в программе.
Немного перефразирую задачу.
Серверная часть оповещает клиентов по циклу по NetBios через TCP. Причем не ожидая ответа, т.е. как бы должно происходить все быстро. Так думает разработчик, ведь это Netbios. Но фактически оповещение берет на себя система и при выключенном компе она ждет отклика несколько секунд. Может быть где-то есть какой-либо параметр, который позволяет уменьшить время ожидания отклика? Как-то так что ли...