Страница частозадаваемых вопросов.

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

Если даже здесь Вы не найдёте интересующий Вас ответ, напишите нам и мы обязательно проконсультируем Вас.

Так устроен протокол cPOP3. Вместе с этим "пустым" запросом пакета, программа (LocalProxy) передаёт серверу запрос на удаление предыдущего, уже полученного пакета. Если такой запрос не передавать, то сервер не удалит пакет, а отдаст его же в следующий раз.
Такое поведение клиента и сервера необходимо, что бы избежать потери почты при обрыве связи.

Робот запускается раз в минуту, хотя, при загруженности сервера, возможны дополнительные незначительные задержки. При каждом запуске, робот ставит полученные задания в планировщик. Если заказов много, то придётся обождать, ибо за раз обрабатывается всего 1 задание, что позволяет распределить нагрузку более равномерно. Если никто не тянет файлы сотнями, то ждать приходится 1-15 минут. Надо понимать и то, что роботу требуется ещё какое-то время, что б скачать файл, обработать и положить в пикап сервера. А финальная задержка - это IIS (Internet Information Server, установленный на нашем сервере), который сам решает, когда отправить почту. Именно из-за него получается наибольшая рандомизация времени ожидания, ведь письма могут быть отправлены мгновенно, а могут пролежать в своеобразном Outbox'е сервера ещё какое-то время.

В любом случаи - если ответа нет, то запрос нахоится в стадии обработки, иначе придёт ответ об ошибке.

Нет, вряд ли, на то есть ряд причин:

• слишком сложный протокол, имеющий уже невероятное число версий и нюансов;
• низкий КПД, ибо 500 байтовый пакет, как ни сжимай - выигрыша почти не будет (а, возможно, ещё и хуже станет из-за использования HTTP в качестве транспортного протокола);
• крайне ненадёжная реализация. Дело тут в том, что HTTP, в принципе, однонаправленный протокол, поэтому осуществлять на его основе двунаправленные протоколы (такие как ICQ, FTP и т.д.) крайне проблематично и, опять же, не эффективно. Самый большой недостаток - отсутствие постоянного подключения клиент-сервер (Keep-Alive проблему практически не решает в данном случаи);
• возможные проблемы, связанные с антиспамовыми и пр. системами защиты ICQ-серверов (ведь у всех наших клиентов будет 1 IP адрес, что может вызвать озабоченность у AOL).

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