|
ru.nethack- RU.NETHACK ------------------------------------------------------------------- From : Oleh Derevenko 2:5020/400 30 Nov 2007 00:18:45 To : All Subject : TCP send() -------------------------------------------------------------------------------- Привет Я веду разборки с разработчиками одной операционной системы (не будем конкретизировать и переходить на личности ;) ) по поводу неправильной реализации TCP-шной функции send(). Есть буфер данных на отправку (SO_SNDBUF). Когда очередной вызов send() помещается в буфер - все нормально. Hо когда буфер почти полон, часть данных вызова помещается в него сразу, а потом вызывающий поток блокируется пока в буфере не появится свободное место. Прикол в том, что когда это самое место появляется, товарищ предоставляет первоочередной доступ к буферу исходя из приоритетов ожидающих потоков. Таким образом, более приоритетный поток может вставить свой блок внутрь блока переданного в send() менее приоритетным потоком и испортить весь поток данных. Посылка блока данных получается не атомарной. Разработчик аргументирует свое решение тем, что никакого конкретного описания как должна себя вести библиотека в таких случаях он не нашел, а предоставлять доступ к буферу отправки данных исходя из приоритета ему кажется логичным. И то, что таким образом он портит структуру данных и делает невозможным использование сокетов из нескольких потоков, его нисколько не смущает: его забота - доставить все байтики, а будет ли получателю от них какая-либо польза - это уже проблемы самого получателя. Короче, он обещал пересмотреть свою позицию, если я предоставлю ему какую-нибудь спецификацию, где четко указано, что надо делать в случае переполнения буфера, или какую-нибудь известную программу, которая не будет работать с такой реализацией send(). Я понимаю, что самое сложное - доказать очевидное. Hо может кто-нибудь поможет ссылочкой на соответствующий документ? Oleh Derevenko -- ICQ: 36361783 --- ifmail v.2.15dev5.4 * Origin: Eleks Software, http://maps.google.com/maps?z=18&ll=49. (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.nethack/25833d886e817.html, оценка из 5, голосов 10
|