Тут выяснилось, что если система обновляет время, то WCF транспорт может упасть, потому как думает, что прошёл таймаут.
Обходом является поднятие соединения снова.

В связи с этим два вопроса: "что за..?" и "что делать?".

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

_NN>В связи с этим два вопроса: "что за..?" и "что делать?".

Если это так, то фигово. Но не смертельно. Сколько раз в неделю ваша система обновляет время? Ну если плохие часы, то максимум на 2-3 секунды в день будет раница. При хороших часах -- это 0.1 сек в сутки.

Так что ошибка маловероятна и retry-паттерн -- вполне себе решение. Думаю что потеря сетевого пакета случается чаще.

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

_NN>Тут выяснилось, что если система обновляет время, то WCF транспорт может упасть, потому как думает, что прошёл таймаут.
_NN>Обходом является поднятие соединения снова.

_NN>В связи с этим два вопроса: "что за..?" и "что делать?".

А WCF тут причем? Проверяет время -- бац, время изменилось, тайм аут истек, ошибка. Это проблема должна решаться не средствами WCF.

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

S>А WCF тут причем? Проверяет время -- бац, время изменилось, тайм аут истек, ошибка. Это проблема должна решаться не средствами WCF.
Можно использовать монотонный таймер, как GetTickCount, который не подвержен системным изменениям времени.

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

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

_NN>>В связи с этим два вопроса: "что за..?" и "что делать?".

S>Если это так, то фигово. Но не смертельно. Сколько раз в неделю ваша система обновляет время? Ну если плохие часы, то максимум на 2-3 секунды в день будет раница. При хороших часах -- это 0.1 сек в сутки.
У нас был тест, который переводит часы на час вперёд.
Когда таймаут был бесконечным, то всё работало, но нашлись другие проблемы

S>Так что ошибка маловероятна и retry-паттерн -- вполне себе решение. Думаю что потеря сетевого пакета случается чаще.
Единственная проблема, что в лог записываются неинтересные сообщения.

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

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

S>>А WCF тут причем? Проверяет время -- бац, время изменилось, тайм аут истек, ошибка. Это проблема должна решаться не средствами WCF.
_NN>Можно использовать монотонный таймер, как GetTickCount, который не подвержен системным изменениям времени.

Так себе решение:

The elapsed time is stored as a DWORD value. Therefore, the time will wrap around to zero if the system is run continuously for 49.7 days.
To avoid this problem, use the GetTickCount64 function. Otherwise, check for an overflow condition when comparing times.

Отсель -- https://msdn.microsoft.com/ru-ru/library/windows/desktop/ms724408(v=vs.85).aspx

При 64 битной версии кол-во дней удвоится, если я не ошибаюсь. Не суть, в любом случае здесь возможен heisenbug.

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


S>При 64 битной версии кол-во дней удвоится, если я не ошибаюсь. Не суть, в любом случае здесь возможен heisenbug.
Удвоится ? Может всё таки увеличится в 2^32 раз?
В любом случае это не проблема т.к. важно чтобы была монотонность, остальное дело техники.

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

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


S>>При 64 битной версии кол-во дней удвоится, если я не ошибаюсь. Не суть, в любом случае здесь возможен heisenbug.
_NN>Удвоится ? Может всё таки увеличится в 2^32 раз?

Я конечно же был не прав. Но и Ваш подсчет меня смущает: разве не квадратичная зависимость, т.е. (49.7)^2 дней?

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

S>Я конечно же был не прав. Но и Ваш подсчет меня смущает: разве не квадратичная зависимость, т.е. (49.7)^2 дней?
Как бы всё просто:

32-бит — масимальное число 2^32
64-бит — масимальное число 2^64

2^64 / 2^32 = 2^32

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

S>Так себе решение:

S>

S>The elapsed time is stored as a DWORD value. Therefore, the time will wrap around to zero if the system is run continuously for 49.7 days.
S>To avoid this problem, use the GetTickCount64 function. Otherwise, check for an overflow condition when comparing times.

S>Отсель -- https://msdn.microsoft.com/ru-ru/library/windows/desktop/ms724408(v=vs.85).aspx

DWORD в MSDN — это беззнаковое число.
Поэтому достаточно скастить результат Environment.TickCount к uint и все будет хорошо.

using System;

namespace Timeout
{
    class Program
    {
        static void Main(string[] args)
        {
            uint prev = uint.MaxValue - 10;
            uint current = 10;
            uint elapsed = unchecked(current - prev);
            Console.WriteLine(elapsed);
        }
    }
}

_NN>В связи с этим два вопроса: "что за..?" и "что делать?".
Давно пора от него отказываться, не модно нонче, сложно жутко и никому на свете не понятно
ВебАпи наше модное всё нонче

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

_NN>Тут выяснилось, что если система обновляет время, то WCF транспорт может упасть, потому как думает, что прошёл таймаут.
_NN>Обходом является поднятие соединения снова.

_NN>В связи с этим два вопроса: "что за..?" и "что делать?".

Проблема не нова, и возникла задолго до WCF и .NET как такового. Общего решения до сих пор нет (да и сама тема перевода дат и работы с временными зонами крайне непростая).

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

_NN>>В связи с этим два вопроса: "что за..?" и "что делать?".
Tom>Давно пора от него отказываться, не модно нонче, сложно жутко и никому на свете не понятно
Tom>ВебАпи наше модное всё нонче
Есть для .NET 3.5 поверх именнованных пайпов?

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

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

_NN>>>В связи с этим два вопроса: "что за..?" и "что делать?".
Tom>>Давно пора от него отказываться, не модно нонче, сложно жутко и никому на свете не понятно
Tom>>ВебАпи наше модное всё нонче
_NN>Есть для .NET 3.5 поверх именнованных пайпов?
И зачем тебе именованные пайпы, про 3.5 я молчу вообще

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

Tom>И зачем тебе именованные пайпы, про 3.5 я молчу вообще
Общаться между процессами.

А 3.5 продуктальное требование, потому что в 7-ке оно из коробки.