SslStream эквивалент TcpClient.Available?

Question

Исходя из рекомендации @ Len-Holgate в этом вопросе , я асинхронно запрашиваю 0-байтовые чтения, а в обратном вызове принимаю байты доступных байтов с синхронными чтениями, так как я знаюданные доступны и не будут блокироваться.Это кажется таким эффективным и замечательным.

Но затем я добавляю опцию для SslStream, и подход разваливается.Считывание нулевого байта в порядке, но SslStream расшифровывает байты, оставляя нулевой счетчик байтов в буфере TcpClient (соответственно), и я не могу определить, сколько байтов теперь в SslStream доступно для чтения.

Есть ли простой трюк вокруг этого?

---

Какой-то код, только для контекста:

sslStream.BeginRead(this.zeroByteBuffer, 0, 0, DataAvailable, this);

И после EndRead () (который правильновозвращает 0), DataAvailable содержит:

// by now this is 0, because sslStream has already consumed the bytes
available = myTcpClient.Available; 

if (0 < available) // Never occurs
{
    // this part can be distractingly complicated, but 
    // it's based on the available byte count
    sslStream.Read(...); 
}

И из-за протокола мне нужно оценивать побайтово и декодировать переменную в байтовой ширине в Юникоде и прочее.Я не хочу асинхронно читать побайтно!

Answer 1

Если я правильно понял, ваши сообщения разделены определенным символом, и вы уже используете StringBuilder для покрытия случая, когда сообщение фрагментировано на несколько частей.

Вы можете рассмотреть возможность игнорирования разделителя при чтении данных, добавлении любых данных в него, когда оно станет доступным, и последующей проверке локального StringBuilder на наличие символа разделителя.Найдя, вы можете извлечь одно сообщение, используя sb.ToString(0, delimiterIndex) и sb.Remove(0, delimiterIndex), пока не останется разделитель.

Это также относится к случаю, когда два сообщения принимаются одновременно.