ZmeisheПроблема в нестабильной работе сети по DSL модему.
Пока клиент-сервер работают в локальной сети офиса, проблем нет. Сетка стабильная.
Когда клиента кладу на удалённый компьютер в другом городе, то работает до тех пор пока пинги непрерывны.
Как только команда пинг пишет "Превышен интервал ожидания", то клиент зависает. Даже если следующие пинги идут нормально - клиент как замороженный, т.е. блокирующий Socket ожидает данные в канале, а они туда, как-будто, не поступают. Но он знает, что ещё не всё выкачал, вот и ждёт.
При этом другая программа, работающая через DCOM, а не Socket, оживает и читает данные.
Мне эту проблему как решать?? Программно или в настройках системы.
Первое, что пришло на ум - резать информацию на мелкие пакеты для передачи, хотя я думал, что этим должны заниматься системные сервисы/демоны.
Кто пишет клиент-серверные приложения - подскажите отчего такое происходит и как побороть?

в зависимости какой уровень юзаете..
если TCP то как раз он берёт на себя задачи по обеспечению канала связи. В том числе и те, которые Вы описали.
если UDP (к примеру) - то он гарантирует только ПЕРЕДАЧУ данных. а дойдут или нет - сель ави... Вы должны в данном случае сделать некие телодвижения по решению проблем, которые могут возникнуть при использовании этого уровня...


с уважением
(круглый)
ЗЫ
Сдаёться мне, что Вы не гоняли ваше приложение (даже в локальной сетке) на предмет отказоустойчивости... Скорее всего Вас ждут много сюрпризов. Это только первый. Последующие (давайте я сделаю умную рожу и проведу сеанс телепатии) возможно будут - сбои или падежи в уже отлаженной области (скажем много-нитеевость) вашего сервака. Когда этот баг с шаманством изведёте, попробуйте сделать следующии тесты...
1) в любой момент времени просто потянуть сетевую фишечку из гнезда сетевухи, во время работы Вашего клиента.
2) запустить Ваших клиентов на 10 машин, по 10 штук на каждой. Попробывать поиграться на разных машинах в разных фазах...
3) запустить несколько Ваших клиентов, и с 5 машин одновременно по 10 пингов, с длиной пакетов в 3000 байт и кол-вом в 1000 на Ваш сервак. Проверить работоспособность Ваших клиентов...
4) поставить в код логина терминэйтед процесс... позапускать раз 20-30 Вашего клиента...
ну и т.д...
список мона продолжать бесконечно...думаю это Вас натолкнёт на толковые размышления...

Zmeishe...Понаблюдаю ещё.

Предположу что юзаете Вы TCP (судя по форточной функции бла-бла-Stream). Если так, то с ОЧЕНЬ большой вероятностью - траблы у Вас в коде. Дело в том, что TCP уровень ГАРАНТИРУЕТ последовательную доставку данных в виде потока. Всё остальное - от лукавого. Точнее можно смело строиться в стройные ряды и идти за нобелевской премией...Точнее к Гейтсу

Чтобы раскрутить ситуацию, попробуйте следующее...
1) взять из МСДНа стандартный пример соединения по TCP и прогнать по нему 500 метров данных...Посмотреть, много подумать...
2) воткнуть к се в программу данные кусочки (клиента) и БЕЗ РАЗБОРКИ данных прогнать эти несчастные 500 метров. клиента оставить пока на форточках...
3) воткнуть в код серверный кусочек с форточек, без разбора(сборки) данных. прогнать...
4) на стороне передатчика - сделать со сборкой большой кусок данных..прогнать...
5) прогнать с разборкой данных, код как в оригинале...

если будете педантно выполнять сие телодвижеия - где нибуть у Вас обнаружиться проблемы. Вот их и решайте...
Можно по другому...
У Вас я надеюсь есть враперы вокруг вшивеньких вентелей вызовов сетевого слоя ? Вот там втупую и поставте счётчики данных... Если нет - то сделайте...После подсчёта трафика уходящего и приходящего - много думать... скорее всего клиент хочет больше, чем послал передатчик. Для избежания таких трабл - нужно Ваш счётчик всего принятых байт передавать как контрльной на более нижнии слои, где идёт парсирование Ваших принятых данных (для контроля длины ожидания)...


удачи Вам
(круглый)
ЗЫ
Поверьте - Вы не первый "открываете америку". Увы и ах - как правило, в 99,9% случаев виноват программист...