Размер буфера приема сокета

Question

Есть ли способ определить размер буфера приема сокета TCPIP в c #.Я отправляю сообщение на сервер и ожидаю ответа, если я не уверен в размере буфера приема.

            IPEndPoint ipep = new IPEndPoint(IPAddress.Parse("192.125.125.226"),20060);
            Socket server = new Socket(AddressFamily.InterNetwork,
                              SocketType.Stream, ProtocolType.Tcp);
            server.Connect(ipep);

            String OutStr= "49|50|48|48|224|48|129|1|0|0|128|0|0|0|0|0|4|0|0|32|49|50";

            byte[] temp = OutStr.Split('|').Select(s => byte.Parse(s)).ToArray(); 

            int byteCount = server.Send(temp);

            byte[] bytes = new byte[255];
            int res=0;
            res = server.Receive(bytes);
            return Encoding.UTF8.GetString(bytes);

Answer 1

Размер буфера, используемого для приема данных, зависит от приложения или протокола.На языке нет способа сказать, каким должен быть размер вашего буфера приема.Также нет функции сокета, которая может использовать «23867 байт для получения этого сообщения».В общем, ваше приложение должно определить из протокола, какой размер должен иметь буфер приема и как с этим справиться.Обычно протокол либо:

• указывает число байтов в сообщении.
• указывает завершающий символ (например, hdlc, использующий 0x7e для обозначения конца сообщения)

Следствием этого является то, что вашему приложению может потребоваться обработка разделенных сообщений.Например, сервер может отправить сообщение размером 2000 байт, но ваш приемный буфер составляет всего 1000 байт, вам нужно будет написать некоторый код, чтобы поддерживать состояние, сообщающее вам, завершили ли вы сообщение или частично завершены.

Answer 2

TCP - это поток байтов.Он ничего не знает о вашей концепции сообщений.

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

Я говорю о формировании TCP-сообщения здесь:http://www.serverframework.com/asynchronousevents/2010/10/message-framing-a-length-prefixed-packet-echo-server.html хотя он относится к коду C ++, поэтому он может быть бесполезен для вас.

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

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

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