Ошибка DrvCnlBasic

[manjey73]

хм, вероятно это работает только в том случае, если выставляешь «Отключаться при ошибке». Если галка с этого параметра снята, то очищения буфера не происходит.

[manjey73]

Хотя логически, если есть код, предполагающий очистку, наличие галки «Отключаться при ошибке», не должно влиять на очистку входного буфера.
В идеале возможность очистки должна быть даже внутри попыток опроса, а не только после сессии.

[manjey73]

з.ы. это принципиально для приборов, когда мы работаем в режиме Com Over TCP, независимо, Линия связи как TCP клиент или как TCP сервер.
Особенно актуально, когда у приборов несколько запросов и ответов в одной сессии.

Прерывать сессию при первом же битом пакете как-то некрасиво :), потому что следующие могут вполне нормально прочитаться.

[Mikhail]

Записал пожелание добавить метод очистки буфера, который можно вызвать из сеанса. Но до реализации дойдёт не скоро.

Добавьте в класс TcpClientChannelLogic вывод в журнал при очистке буфера, чтобы проверить вызов этого метода. Скомпилируйте dll у себя.

[manjey73]

Вариант при отключении линии. Дополнительных логов нет, но каждую сессию ответ с начала

2025-06-24 17:11:05 Отключение от ::ffff:192.168.0.8

2025-06-24 17:12:00 Соединение с 192.168.0.8:4001

2025-06-24 17:12:00 Сеанс связи с устройством [49] Mbus_SDM
Отправка (5): 10 40 FD 3D 16
Отправка (9): 68 03 03 68 73 01 B1 25 16
Приём (4/4): 68 90 90 68
Приём (74/146): 08 01 72 78 56 34 12 FF FF 01 02 55 00 00 00 0B FD 47 32 25 02 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 59 15 04 00 0B FD 59 00 00 00 0B FD 59 00 00 00 0B FD 59 00 00
Ошибка: некорректная длина ответа!
Получено за 1131 мс

2025-06-24 17:12:01 Отключение от ::ffff:192.168.0.8

2025-06-24 17:13:00 Соединение с 192.168.0.8:4001

2025-06-24 17:13:00 Сеанс связи с устройством [49] Mbus_SDM
Отправка (5): 10 40 FD 3D 16
Отправка (9): 68 03 03 68 53 01 B1 05 16
Приём (4/4): 68 90 90 68
Приём (70/146): 08 01 72 78 56 34 12 FF FF 01 02 55 00 00 00 0B FD 47 75 26 02 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 59 19 04 00 0B FD 59 00 00 00 0B FD 59 00 00 00 0B
Ошибка: некорректная длина ответа!
Получено за 1116 мс

2025-06-24 17:13:01 Отключение от ::ffff:192.168.0.8

А вот без отключения

2025-06-24 17:30:23 Соединение с 192.168.0.8:4001

2025-06-24 17:30:23 Сеанс связи с устройством [49] Mbus_SDM
Отправка (5): 10 40 FD 3D 16
Отправка (9): 68 03 03 68 53 01 B1 05 16
Приём (4/4): 68 90 90 68
Приём (70/146): 08 01 72 78 56 34 12 FF FF 01 02 55 00 00 00 0B FD 47 20 23 02 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 47 00 00 00 0B FD 59 15 04 00 0B FD 59 00 00 00 0B FD 59 00 00 00 0B
Ошибка: некорректная длина ответа!
Получено за 1107 мс
Очистка буфера Клиента выполнена

2025-06-24 17:31:00 Сеанс связи с устройством [49] Mbus_SDM
Отправка (5): 10 40 FD 3D 16
Отправка (9): 68 03 03 68 73 01 B1 25 16
Приём (4/4): FD 3A 00 00
Приём (23/60): 0A FD 3A 00 50 3E 16 68 90 90 68 08 01 72 78 56 34 12 FF FF 01 02 55
Ошибка: некорректная длина ответа!
Получено за 926 мс
Очистка буфера Клиента выполнена

а ничего не очищается, то есть абсолютно

Вставлен лог сюда

        public override void AfterSession(DeviceLogic deviceLogic)
        {
            if (currentConn != null)
            {
                if (currentConn.Connected)
                {
                    if (!options.StayConnected || options.DisconnectOnError &&
                        deviceLogic.DeviceStatus == DeviceStatus.Error)
                    {
                        Log.WriteLine();
                        Log.WriteAction(Locale.IsRussian ?
                            "Отключение от {0}" :
                            "Disconnect from {0}", currentConn.RemoteAddress);
                        currentConn.Disconnect();
                    }
                    else if (deviceLogic.DeviceStatus == DeviceStatus.Error)
                    {
                        currentConn.ClearNetStream(inBuf);
                        Log.WriteLine($"Очистка буфера Клиента выполнена"); // TEST
                    }
                }

                if (Behavior == ChannelBehavior.Slave)
                    Monitor.Exit(currentConn.SyncRoot);
            }
        }

• Ответ изменён 12 месяцев назад пользователем manjey73.

[manjey73]

Метод выполняется, очистка нет.

[manjey73]

NetStream.DataAvailable — при этом true, посмотрел в отладчике

[Mikhail]

Метод ClearNetStream очищает ограниченное количество данных из буфера. Либо он очистил не все данные, либо после очистки пришли новые данные.

[manjey73]

Новые данные не могут прийти по причине единственного запроса.
Например в драйвере DrvMBus у меня просто не реализованы повторы опросов на данный момент.
При timeout 1000 весь запрос успевает прийти. Следующий опрос в следующей сессии через 30 секунд, там то, что должно было прийти пришло бы уже раз 30-ть. Однако прилетает хвост предыдущего запроса. В СЛЕДУЮЩЕЙ СЕССИИ блин….

мне все же кажется, что ничего он не очищает, пытаться может и пытается, но не чистит.

там 142 байта если что, на весь ответ + заголовок 4 байта. Это насколько ограниченное количество ?

[manjey73]

При этом если выставить «Отключение по ошибке», данные метод уже не вызывается, и в следующей сессии данные идут с начала, как и положено.
Вероятно там другие механизмы работают, возможно создание буфера с нуля (предположу)

[manjey73]

Соврал. 146+4 байта, всего 150 байт на ответ.
И непонятное подозрение, как считается timeout тут, ведь сперва мы прочли заголовок, остановились, потом читаем 146 байт и timeout там снова 300мс (я выставил), за 300мс успевает прочитать только 70 байт ?

хотя там скорость прибора 2400, но все равно должен раза в 3 больше успеть принять.

[Mikhail]

При каждом чтении таймаут считается заново.
По TCP данные приходят постепенно, это в порядке вещей. Если таймаут слишком маленький, то как раз к следующей сессии придёт новая порция данных и испортит опрос.

[manjey73]

Не понимаю о какой постепенности в TCP идет речь, я же читаю не файл какой-то из прибора, а всего 150 байт, который прибор отправляет ОДИН раз. Откуда берется вторая часть ответа через 30 секунд ?

Вот отправил прибор 150 байт, а timeout у меня ниже, чем может обработать эти 150 байт. Получается просто не успел. При этом я вызвал DeviceStatus == DeviceStatus.Error, буфер должен быть очищен.
Ну не успел и не успел — откуда он взял на следующей сессии кусок прошлого ответа?

Он должен был остаться в буфере и по окончании сессии очищен. И на новой сессии я так же при своих настройках должен получить только начало нового ответа. Раз я подаю команду статуса ошибки.

[manjey73]

Ну банальный пример. c timeout у нас все хорошо, но в процессе приема ответа происходит обрыв связи, timeout так же честно отрабатывает.

Сессия раз в минуту например, да даже и 30 сек. Устройство ответ отправило? — отправило.
Повторять отправку не намерено, ну тупое оно, без запроса повторов не делает.

Попадаем в ту же ситуацию.

[manjey73]

Я правильно понимаю, что в текущей реализации это проблема System.Net.Sockets.NetworkStream и не лечится ?

[Автор]

Сообщения