SOCKET и потоки (и ещё MFC::CAsyncSocket)

[lapulya]

pups, Тут дело вот в чем, протокол TCP потоковый, поэтому если протокола нет (вод протоколом имеется ввиду хоть какие-то правила передачи и приема данных), то ничего получить или принять нельзя. Т.е. если с сервера начинает как из крана литься данные и ты не в состоянии ни как понять когда они кончатся (исходя из самих данных), то написать клиент-серверное приложение нельзя!!!

[pups]

Я по этому и написал "много букав - не осилил", я же не говорю, что это не рабочий вариант, просто я так понял пупсу нужна концепция и я, а точнее Вад чуть раньше предложил наиболее простую. Это также протокол, только он много проще - всего надо передавать в начале пакета (первыми 4 байтами ну или как договоримся) размер данных пакета и все.

Теорию я понял, даже сам пробовал это реализовать, но использовать GetSockOpt с параметром SO_RCVBUF не получается. Нифига этот GetSockOpt не работает. Если бы работал, то я бы знал размер передаваемых данных и закрутил бы цикл.

То же самое предлагает микрософт в мсдн:
   idx = 0;

    while (nLeft > 0)
   {
      ret = recv(m_sConnectSocket, &recvbuff[idx], nLeft, 0);
      
      if (ret == SOCKET_ERROR)
      {
         goto end_fu;
        // Error
      }
      idx += ret;
      nLeft -= ret;
   }
Но мы не знаем размер поступаемых данных nLeft. Если бы знать точно размер в байтах, то вопрос был бы снят сам собой.

[Вад]

pups, ок, если сервер у тебя уже есть - протокол отбрасываем, тебе нужно поддерживать тот, который предоставляется сервером. Точнее, так: при закачке, есть у тебя возможность узнать размер получаемой информации для конкретного сеанса до начала самой закачки? Или всё, что у тебя есть - это порт на сервере, куда ты подключаешься, и тебе льют данные? Если последнее - то что делает сервер потом, неужели оставляет соединение открытым?
Словом, нужна конкретика о взаимодействии с сервером в рамках сеанса.

[lapulya]

Вад, ну я именно это и написал - давай протокол (он должен быть) без него не понятно что вообще сервер делает и что и как делать с полученными данными.

[pups]

pups, Тут дело вот в чем, протокол TCP потоковый, поэтому если протокола нет (вод протоколом имеется ввиду хоть какие-то правила передачи и приема данных), то ничего получить или принять нельзя. Т.е. если с сервера начинает как из крана литься данные и ты не в состоянии ни как понять когда они кончатся (исходя из самих данных), то написать клиент-серверное приложение нельзя!!!

Согласен. Откуда берется событие получения данных? Событие берется от того, что изменилось состояние сокета. В зависимости от состояния определено событие. Тогда как получить текущее состояние сокета? Если состояние сокета "в покое", то я могу передавать данные. Я же отслеживаю все события системы (реагирую на них) в режиме ожидания, значит могу прикрутить проверку состояния сокета. НО КАК СДЕЛАТЬ ПРОВЕРКУ? Это было бы идеальным решением.

Вад, ну я именно это и написал - давай протокол (он должен быть) без него не понятно что вообще сервер делает и что и как делать с полученными данными.

Тогда это должен быть протокол работы сокета, а не протокол передачи данных. Я правильно понимаю?

Дополнительно. И как это все реализовать? У меня мозгов не хватает. Я это никогда не делал и понятия не имею с какой стороны "подойти" к данному вопросу.

[Вад]

pups, не-не-не. Когда уже из сокета "течёт", ты не можешь лишь по одному "течёт" и "перестало течь" сделать вывод, что данные кончились. Для определения, поступили в сокет данные или нет, есть select (и должен быть аналог - а точнее, обёртка к нему - у AsyncSocket). Точнее, select можно вызывать сразу для массива сокетов. Впрочем, если это единственное, что тебе нужно...

[pups]

Мы говорим о AsyncSelect или просто о select? Пол моему это одно и то же. Я использую все события, но их там не достаточно чтобы узнать когда кончились данные.
Акцепт - используетесся только на сервере, ждет поступления сообщений.
Клосе - Событие когда прервали соединение.
Коннект - когда соединились.
Аут оф Банд дата - для служебных сообщений (инфы по нему очень мало) т.к. даже майкрософт говорит, что люди его отказываются использовать, а создают паралельные сокеты.
Рецейв - Получаем
Сенд - отправляем.

Других событий нет, а этих не достаточно для решения моей задачи. Как я понимаю АсинкСокет происходит из Ц обьект. Более нижнего уровня нет. Далее из Асинк сокета выходит клас Ц Сокет.

По этому если писать что либо связанное с большим количеством событий, то это на уровне Ц обьекта?
Чего то у меня мозги дымят. У меня уже 4 утра. Иду спать.

Что Вы посоветуете использовать? Вы наглядно представляете решение данной задачи? Вы можете мне обьяснить решение?

[lapulya]

pups, честно говоря про MFC ничего не знаю, особенно про сокеты, но на уровне API понять по сокету когда кончились данные нельзя. Никак нельзя, вот хоть тресни...

Поэтому еще раз говорю протокол обязателен. Обычно или скажем так, часто делают так: надо послать сообщение (пакет) размером в "к" байт. Что делают, а вот что - сначала шлют данные размером в sizeof(long) (причем на обоих хостах они должны совпадать). на принимающей стороне в цикле принимаем ровно sizeof(long) байт (как это делается я показывал), приняв их и скастовав в long смотрим каков же размер "пакета" (заметь слово пакета я пишу в кавычках, потому как нет в tcp понятия пакет - это потоковый протокол, у меня язык отсох это повторять на форуме каждый второй интересующийся сокетами этого недопонимает, но это я не в обиду, а так между прочим). Узнав размер пакета опять в цикле его принимаем, пока не примем весь или пока не порвется соединение ил не получим какую нить ошибку. вот и вся наука. Но это все хорошо, когда сервер (который я так понял ты изменить не можешь), следует описанному правилу (который можно смело назвать и протоколом). В любом случае какой-то протокол (читай правила отправки и приема данных) сервер должен реализовать, иначе никак...

[Алексей++]

pups, lapulya, забудьте про MFC - не MFC . CAsyncSocket внутри ничем не отличается от обычных сокетов (он же их и использует) , просто обработка сообщений более удобная.

pups, пока не узнаешь протокол, который использует сервер - помочь никто ничем не сможет, это факт
Если устал - надо поспать, работоспособность резко падает, когда так

[pups]

pups, lapulya, забудьте про MFC - не MFC . CAsyncSocket внутри ничем не отличается от обычных сокетов (он же их и использует) , просто обработка сообщений более удобная.

Вы меня окончательно запутали. Есть почтовый сервер. Нужно получить с него миллион писем. Все они разного размера. Как мне узнать, что предыдущее письмо получено, чтобы отправить очередной запрос? Протокол POP3. Не уж то об этом люди не подумали? У меня не получается получить информацию, что предыдущее письмо окончательно получено.

[Алексей++]

pups, ну вот, уже прогресс )) Протокол известен. Бери описание и вперёд - посылай запросы, получай ответы. с POP3 я не работал, только отправку писем делал, поэтому тут уже не подскажу

http://ru.wikipedia.org/wiki/POP3

[RXL]

pups, стандарт читал?
RFC1939 - Post Office Protocol - Version 3

[pups]

pups, стандарт читал?
RFC1939 - Post Office Protocol - Version 3

Знаю этот протокол как "Отче наш ...". Если Вы говорите о получении размера письма по номеру, то этот номер иногда не проходит. Некоторые сервера не поддерживают эту команду. Проверено и даже не обсуждается. Например майл.ру бывает ВРЕМЕНАМИ, что не поддерживате эту команду.  Что то нужно другое намудрить. Программа подразумевает круглосуточную работу нужна максимальная стабильность.

[pups]

pups, ну вот, уже прогресс )) Протокол известен. Бери описание и вперёд - посылай запросы, получай ответы. с POP3 я не работал, только отправку писем делал, поэтому тут уже не подскажу
http://ru.wikipedia.org/wiki/POP3

Отправку делал по SMTP с авторизацией или если протокол открыт?

[RXL]

pups, каждое сообщение завершается строкой с точкой - используй этот маркер.

[pups]

Я ранее уже об этом писал.  Эта точка может быть использована тыщу раз в одном письме. Нельзя о нее опираться.

[Алексей++]

pups,

SMTP с авторизацией

да, это же тоже стандарт. А адрес smtp-сервера у меня в программе вообще юзер вводил сам

Я ранее уже об этом писал.  Эта точка может быть использована тыщу раз в одном письме. Нельзя о нее опираться.

читал говоришь ? ) Точка то тосле ентера

When all lines of the response have been sent, a
   final line is sent, consisting of a termination octet (decimal code
   046, ".") and a CRLF pair.

[pups]

читал говоришь ? ) Точка то тосле ентера

Тема закрыта. Спасибо. Простите что побеспокоил.

[Вад]

Я ранее уже об этом писал.  Эта точка может быть использована тыщу раз в одном письме. Нельзя о нее опираться.

Может, я чего не понимаю. Но команда LIST, да и RETR, судя по спецификации, отдаёт число октетов (читай: размер) каждого письма. Неужели не прочитать столько октетов, сколько сказано?

[RXL]

Вад, https://forum.shelek.ru/index.php/topic,14734.msg196536.html#msg196536
Попадаются дурные почтовики.

pups, точка - одна на строке - в теле письма быть не может, т.к. SMTP использует тотже маркер приотсылке письма. По это причине текст письма, который может конфликтовать, кодируют в base64 и т.п.

[pups]

Я ранее уже об этом писал.  Эта точка может быть использована тыщу раз в одном письме. Нельзя о нее опираться.

Может, я чего не понимаю. Но команда LIST, да и RETR, судя по спецификации, отдаёт число октетов (читай: размер) каждого письма. Неужели не прочитать столько октетов, сколько сказано?

Спасибо за помощь. Тема закрыта.