непонятки с read() - часть 2

чувак, делаешь рид и определеяшь если клиенту приходит команда за которой должна следовать еще команда, запускаешь еще один рид!
У тебя должен быть списко команд за которыми последует еще одна команда!


А вообще тиы не умеешь формулировать вопрос! И второе, все зависит от протокола...........там хоть 100 комманд может идти от сервера. Ты должен 100 раз рид вызвать!

> А вообще тиы не умеешь формулировать вопрос! скорее всего, ты не видел моего первого поста

еще раз объясню суть задачи (упрощу немного): пусть мой клиент посылает мной написанному серверу команду ls. сервер читает каталог (на удаленной машине) и шлет в ответ или одну строку (.) или несколько (. + список файлов). IMAP-сервер также откликается либо одной строкой либо несколькими. Вот и весь вопрос - где признак конца передачи от сервера? я же не могу заранее знать, сколько файлов окажется в каком-то каталоге или сколькими строками ответит IMAP-сервер?

кстати в ответах на первый пост мне намекнули на select() - возможно это выход, буду копать.

нет tcp потоковый протокол и не обеспечивает атомарность чтения\записи приложение должно само определять где начинаеться закачивается сообщение (возможно использовать какие-то свои теги) и седеть в select`e а по приходу данных складывать их в буффер и проверять на наличие тега конца сообщения ну или надо брать udp.

Странно ... ты решил, что IMAP - подходящий пример. Я не совсем понимаю, на чем ты основывался, но тем не менее. После этого ты не стал читать RFC по этому протоколу (что было бы естественно и многому бы тебя научило), а написал очередной вопрос в конференцию.

По первому вопросу. Нет, ты неправильно понял, что "несколько строк надо читать столькими же вызовами Read()".

По второму вопросу. К сожалению, я не могу сообщить тебе ничего дополнительно к уже сказанному в предыдущей серии ответов на твой вопрос: корректно определить, что "эта строка была последней", нельзя на уровне TCP, и эта задача должны решаться на более высоком уровне. В примере с IMAP последняя строка в ответе сервера характерна тем, что начинается с идентификатора клиентского запроса.

Мой "намек на select", если ты помнишь, сопровождался комментарием, что такой путь странный и по нему лучше не ходить.

еще раз всем спасибо!

посмотрел и RFC по IMAP и описание select(). Все стало ясно: определение конца передачи ДЕЙСТВИТЕЛЬНО надо возлагать на уровень приложений, у TCP для этого просто ничего нет.

Купил книгу У.Стивенса "Сетевое программирование" - больше никого доставать не буду.

чувак, тебе нужно разработать протокол, повторяю еще раз!!!

Например,

<start>

тут ридов от нуля до скака влезит

<stop>


пока не пришел стоп, вызываешь риды и обрабатываешь, пришел стоп - ВСЕ!!! Конец передачи!!!

>Купил книгу У.Стивенса "Сетевое программирование"

Молодец.

> - больше никого доставать не буду.

Вдвойне молодец ;)

Понятно, что никто никого не заставлял отвечать на твои вопросы, и люди это делают исключительно потому, что им нравится. Но еще приятнее видеть, что ответы идут на пользу ;)