Какое то время когда клиент законектился к серверу
все ок ,но по истечению некоторово времени
клиенты уже не ловят события , такое ощющение
что теряется коннект , но могу ошибится .
причем на моем компе (Win2k) все ок , и нормально работает,
а на других где win98 вот такая вот беда.
где что копнуть ?

JS>Какое то время когда клиент законектился к серверу
JS>все ок ,но по истечению некоторово времени
JS>клиенты уже не ловят события , такое ощющение
JS>что теряется коннект , но могу ошибится .
JS>причем на моем компе (Win2k) все ок , и нормально работает,
JS>а на других где win98 вот такая вот беда.
JS>где что копнуть ?

если хочется отключить Pinging, то смотри в сторону MSHLFLAGS_NOPING
но тогда прийдётся переписывать фабрику класса или реализовывать IMarshal

Здравствуйте, Tom, Вы писали:

JS>>Какое то время когда клиент законектился к серверу
JS>>все ок ,но по истечению некоторово времени
JS>>клиенты уже не ловят события , такое ощющение
JS>>что теряется коннект , но могу ошибится .
JS>>причем на моем компе (Win2k) все ок , и нормально работает,
JS>>а на других где win98 вот такая вот беда.
JS>>где что копнуть ?

Tom>если хочется отключить Pinging, то смотри в сторону MSHLFLAGS_NOPING
Tom>но тогда прийдётся переписывать фабрику класса или реализовывать IMarshal

хотелось бы без переписывания , так как в СОМ еще не силен
может это какая то системная больше ошибка ?

JS>хотелось бы без переписывания , так как в СОМ еще не силен
JS>может это какая то системная больше ошибка ?

В w2k sp2 есть бага по этому поводу. В других версиях ненаблюдается. Так что бага скорее всего у тебя.
Вот пару идей:
1. Возможно отвалился один из клиентов, и другие не вызываются из за этого.
2. Клиента, который экспортирует call back интерфейс лучше помещать в MTA а не STA.

Здравствуйте, Tom, Вы писали:


Tom>1. Возможно отвалился один из клиентов, и другие не вызываются из за этого.
Tom>2. Клиента, который экспортирует call back интерфейс лучше помещать в MTA а не STA.

про первый случай ,
а как это можно проверить узнать .

про второй , можно поподробней ..

Tom>>1. Возможно отвалился один из клиентов, и другие не вызываются из за этого.
Tom>>2. Клиента, который экспортирует call back интерфейс лучше помещать в MTA а не STA.

JS>про первый случай ,
JS> а как это можно проверить узнать .
Да собственно отследить HRESULT при вызове события.... (это внутри Fire_...)

JS>про второй , можно поподробней ..
А чего тут подробнее. Всё просто. Если клиент в MTA — то вызов прийдёт из потока пула RPC. Если в STA — то в том потоке, который собственно и экспортировал callback, а это означает, что если он чем то занят длительным то вызов не будет произведён покуда поток не соизволит обработать очередь сообщений, а соответственно и все другие клиенты не получат евент (это естественно справедливо если евенты рассылаются все в одном потоке).

Здравствуйте, Tom, Вы писали:

JS>> а как это можно проверить узнать .
Tom>Да собственно отследить HRESULT при вызове события.... (это внутри Fire_...)
Если клиент завис на обработке события, HRESULT не поможет.
Надо делать асинхронную рассылку на сервере и/или асинхронную обработку на клиенте.

Tom>>Да собственно отследить HRESULT при вызове события.... (это внутри Fire_...)
RB>Если клиент завис на обработке события, HRESULT не поможет.
RB>Надо делать асинхронную рассылку на сервере и/или асинхронную обработку на клиенте.

Почему не поможет. Поможет выяснить, что проблемма не в Pinging, а именно в том, что один из клиентов отвалился и следовательно события не приходят остальным именно из за него...

Здравствуйте, rus blood, Вы писали:

RB>Здравствуйте, Tom, Вы писали:

JS>>> а как это можно проверить узнать .
Tom>>Да собственно отследить HRESULT при вызове события.... (это внутри Fire_...)
RB>Если клиент завис на обработке события, HRESULT не поможет.
RB>Надо делать асинхронную рассылку на сервере и/или асинхронную обработку на клиенте.

ну на клиенте
у меня сделанно так

в обработчике события

...::onSend(...)
{
...
PosMessage(...);
}

что бы управление серваку быстро возврашать.