我不知道如何解决这个问题,流做了它应该做的事情(在开始时),这是一个我不希望它做它为…做的事情的场合.

我是否应该尝试重写等待流,或者是否有一种不同的readall方法可以在我的情况下更好地工作？

我已经尝试在没有更多可用数据包时返回0(当我希望它读取所有数据而不是等待时)但是它会抛出流结束异常的IO结束.

我真的很茫然,我知道我为自己挖了一个深洞……

到目前为止,我还没有能够提出一个更好的解决方案,而不是从总长度中减去TLS标题和GCM IV和MAC(如下所述)这对我现在使用的1套件工作正常,但不能很好地吹嘘用于未来的密码套件.

关于我为什么这样做的一些背景：
我正在使用https://github.com/bcgit/bc-csharp来创建基于TLS的加密,但是由于限制,我无法为其分配TCP流,我得到的是来自TCP层的字符串,我无法为其提供适当的TCP流.

我正在使用mockPskTlsServer and client并且我已经创建了它：

WaitingStream mStdin = new WaitingStream();
WaitingStream mStdout = new WaitingStream();
CryptoPskTlsClient mServer = new CryptoPskTlsClient(null);
SecureRandom secureRandom = new SecureRandom();
TlsClientProtocol TlsProtocol = new TlsServerProtocol(Stdin,Stdout,secureRandom);
TlsProtocol.Connect(mServer);

这样工作正常,我还在等待流中添加了一个事件,当流的输出时会触发该事件.这样我就可以在创建它时获得多个握手消息.

这一切都运行良好,本来可以做得更好(不那么……被黑了？)但它确实做了它应该做的事情.

我知道如何让它工作,但这是一个HACK,我正在寻找一种优雅的方式来做到这一点.以下是其中一个HACKS的代码示例：

public override string DecryptData(string ciphertext)
{
    byte[] ciphertextBuff = ASCIIEncoding.Default.GetBytes(ciphertext);
    mStdin.Write(ciphertextBuff,ciphertextBuff.Length);

    Stream tlsStream = mServerProtocol.Stream;
    byte[] plaintextBuffer = new byte[ciphertextBuff.Length - 29];//filthy HACK 29 bytes bij AES-GCM want TLS packet = 5,GCM IV = 8,GCM-MAC = 16 totaal = 29.
    Streams.ReadFully(tlsStream,plaintextBuffer);

    string plaintext = ASCIIEncoding.Default.GetString(plaintextBuffer);
    return plaintext;
}

或者通过将x保留字节中的明文长度预先添加到TLS包中并在解密之前检索这些字节.

但正如您可以从代码示例中清楚地看到,read fully方法中的缓冲区必须是我想要提取的字节长度,它可能小于流所具有的但却不能更多,因为它会无限期地等待.

当我在谈论像ReadAll和ReadFully I mean these methods这样的方法时