NNTP - Обсуждение сайта

Здравствуйте IT, Вы писали:

А>>Там есть доступ через NNTP

IT>Создать то мы можем, только кто туда ходить будет? Вот например там есть очень интересная и нужная конференция Язык C#, только там всего 10 сообщений и больше врядли будет. И потом там эти... как их... банеры. А мы откровенно очень не любим банеры.

Баннеры суксъ. А NNTP рулез. Предлагается вот что: на каждом nntp сервере есть база сообщений. Есть и протокол синхронизации таких баз (NNTP зовется). По этому протоколу можно ходить на ньюссервер кучей разных клиентов, в том числе и оффлайновых, т.е. допускающих скачивание базы (или апдейтов к базе) и просмотр в оффлайне.

Если вы каким-то образом синхронизируете форумы RSDN c чем-то на толкру, то потом туда ходить можно будет простым советским аутлуком-экспрессом, без баннеров, разумеется, что и требовалось. Идеально было бы завести там что-то в fido7 иерархии, объявить вас модераторами, и с этим уже синхронизоваться.

Софт для двухсторонней синхронихации с толкру по NNTP будет по определению NNTP сервером. И туда можно тоже будет ходить аутлуком.

А в каком смысле у вас NNTP нет? Порты закрыты? Тогда нужно придумывать иные способы синхронизации с толкру, что, увы, практическиy неделаемо.

Так вы подумали про talk.ru?

Здравствуйте Аноним, Вы писали:

А>Так вы подумали про talk.ru?

Мы подумали и, пока, не нашли никакого технического решения. Существует две проблемы:

Отправка сообщений.
Приём сообщений и синхронизация их с нашей базой.

Если есть идеи — welcome.

Здравствуйте IT, Вы писали:

IT>Если есть идеи — welcome.

Поменять сервер

Здравствуйте adontz, Вы писали:

A>Поменять сервер

На какой?

Здравствуйте IT, Вы писали:

IT>Здравствуйте adontz, Вы писали:

A>>Поменять сервер

IT>На какой?

На почти любой другой...
IMHO на перл можно много чего написать полезного. (о сишных CGI и ISAPI даже не говорю) хостьтесь там где это чудо разрешают
Неужели нет таких серваков ?

Здравствуйте adontz, Вы писали:

A>Неужели нет таких серваков ?

Я пока не видел провайдеров, предоставляющих сабж.

Здравствуйте IT, Вы писали:

IT>Здравствуйте adontz, Вы писали:

A>>Неужели нет таких серваков ?

IT>Я пока не видел провайдеров, предоставляющих сабж.

БУДЕМ ИСКАТЬ !!!

Здравствуйте IT, Вы писали:

Кстати а сколь мег сайчас жрёт RSDN ???

Здравствуйте adontz, Вы писали:

A>Кстати а сколь мег сайчас жрёт RSDN ???

Весь штоли или только форумы? Mdb с форумами прямо сейчас 23629824 байта

Здравствуйте IT, Вы писали:

IT>Здравствуйте adontz, Вы писали:

A>>Неужели нет таких серваков ?

IT>Я пока не видел провайдеров, предоставляющих сабж.

Я тут подумал... Можно написать туннелирование NNTP поверх HTTP. Юзеры могут ставить на своей машине прокси, который выглядит как NNTP сервер. И это прокси будет общаться с форумами через страничку типа www.rsdn.ru/forum/proxy.asp?cmd=IHAVE,msgid=XXXX (либо LIST либо NEWNEWS), в духе RFC 997. А юзеру будут доступны форумы через ньюсочиталку, в том числе и оффлайновую.

Это имеет смысл затеваться, если IT готов дописать такой интерфейс к своему форуму. Либо сырцы отдать. Если да — то надо идти на сорсфордж, согласовывать интерфейс туннелирования.

Ы?

Здравствуйте George_Seryakov, Вы писали:

GS>Это имеет смысл затеваться, если IT готов дописать такой интерфейс к своему форуму. Либо сырцы отдать. Если да — то надо идти на сорсфордж, согласовывать интерфейс туннелирования.

Это можно. Про сырцы не знаю (не потому что жалко, а потому что боюсь злобных хакеров

), а согласовать и сделать интерфейс на сайте, думаю, будет не сложно. Но опять же, как делать клиентскую часть я себе слабо представляю.

Здравствуйте IT, Вы писали:

IT>Здравствуйте George_Seryakov, Вы писали:

GS>>Это имеет смысл затеваться, если IT готов дописать такой интерфейс к своему форуму. Либо сырцы отдать. Если да — то надо идти на сорсфордж, согласовывать интерфейс туннелирования.

IT>Это можно. Про сырцы не знаю (не потому что жалко, а потому что боюсь злобных хакеров ;) ), а согласовать и сделать интерфейс на сайте, думаю, будет не сложно. Но опять же, как делать клиентскую часть я себе слабо представляю.

OK, с меня спецификация интерфейса. Клиентская часть — RFC 977, TCP программирование. Никто, кстати, не знает NNTP сервера под виндами в сырцах? Нарезать из него и самим не заморачиваться.

И еще вопрос — таки http://sourceforge.net? Или держим проект на rsdn (а вообще есть желание и возможность)?

ГС

Здравствуйте Аноним, Вы писали:

А>OK, с меня спецификация интерфейса. Клиентская часть — RFC 977, TCP программирование. Никто, кстати, не знает NNTP сервера под виндами в сырцах? Нарезать из него и самим не заморачиваться.

А зачем TCP, можно ведь WinInet'ом обойтись.

А>И еще вопрос — таки http://sourceforge.net? Или держим проект на rsdn (а вообще есть желание и возможность)?

А что лучше?

Здравствуйте IT, Вы писали:

IT>А зачем TCP, можно ведь WinInet'ом обойтись.

А на нем TCP запрограммить можно? :-O

А>>И еще вопрос — таки http://sourceforge.net? Или держим проект на rsdn (а вообще есть желание и возможность)?

IT>А что лучше?

Тебе выбирать. Если имеешь возможность и желание развернуть CVS сетевой, то лучше здесь. Иначе — sf.

UC

Здравствуйте Аноним, Вы писали:

IT>>А зачем TCP, можно ведь WinInet'ом обойтись.

А> А на нем TCP запрограммить можно? :-O

На нём можно HTTP програмить.

IT>>А что лучше?

А> Тебе выбирать. Если имеешь возможность и желание развернуть CVS сетевой, то лучше здесь. Иначе — sf.

Не, не знаю я никаких CVS, давай на sf.

Здравствуйте IT, Вы писали:

IT>Здравствуйте Аноним, Вы писали:

IT>>>А зачем TCP, можно ведь WinInet'ом обойтись.

А>> А на нем TCP запрограммить можно? :-O

IT>На нём можно HTTP програмить.

IT>>>А что лучше?

А>> Тебе выбирать. Если имеешь возможность и желание развернуть CVS сетевой, то лучше здесь. Иначе — sf.

IT>Не, не знаю я никаких CVS, давай на sf.

Значит, так:

Сокетный интерфейс я... спрототипировал. И теперь нуждаюсь в совете. Даже в двух.

Приложение естественно разбивается на две части — 1) сокетную часть с паралеллизмом, ивентами и довольно низкоуровневым программированием. И 2) преобразователь данных, который будет взамодействовать с форумом и отдавать данные сокетной части для передачи. Вторую часть, вроде, неплохо сделать КОМ-сервером (первая уже сервис), сменным под разние форумы на разных сайтах.

Первый вопрос такой: на каком языке естественно писать слой обработки данных? Чтоб по HTTP общался, разбирал (XML-ные?) ответы сервера и строки разрезал/склеивал/преобразовывал. Напрашивается VB (коряв, однако), Java (течет, однако, да и не знаю я ее толком) и C++ с развитой классовой структурой (закат солнца вручную, однако).

Второй вопрос: Данные какого уровня абстракции передавать между сокетным слоем и слоем преобразования? Идея такая, что данные (списки мессаджей) призодят пакованные в HTML, потом из надо бы распаковать во внутренне представление, гарантирующее соответсвие их формата стандарту (структурированные данные), а потом опять собрать в голый текст для передачи по TCP (там что-то очень похожее на интерфейс командной строки). Выбор идет между структурированными данными и неструктурированными, и какой-то комбинацией между ними.

Ну и надо уже думать о том, что будет канализированно в HTTP.
Нужны следующие команды (ответы на них):

Каждая статья должны быть снабжена уникальным msgid, статьи в группе должны быть пронумерованы.

На сорсефорже sourceforge.net проект я завел, называется rsdn2nntp. Он пустой пока.

ГС

Здравствуйте George_Seryakov, Вы писали:

GS>Первый вопрос такой: на каком языке естественно писать слой обработки данных?

Давай C++, с #import там всё не немного сложнее васика.

GS>Второй вопрос: Данные какого уровня абстракции передавать между сокетным слоем и слоем преобразования?

Я опишу возможности сервера, а ты уже смотри сам.
На сервере мы не можем запускать ничего кроме скриптов и стандартных COM-объектов. Писать свои расширения и COM-объекты мы не можем, но я и не вижу в этом особенной необходимости. Данные мы можем принимать в XML-формате, либо напрямую использовать существующую форму посылки сообщения. XML предпочтительнее, т.к. не придётся ничего менять, если изменится форма ввода нового сообщения. Отдавать данные можно тоже в XML'е или в любом другом формате, который будет удобней. Мы не можем принимать сообщения в HTML, это должен быть обычный текст. Так же надо будет подумать об аутентификации пользователей.

Здравствуйте IT, Вы писали:

IT>Здравствуйте George_Seryakov, Вы писали:

GS>>Первый вопрос такой: на каком языке естественно писать слой обработки данных?

IT>Давай C++, с #import там всё не немного сложнее васика.

Дык дал уже, но продолжаю подозревать, что знал бы я лучше джаву...

GS>>Второй вопрос: Данные какого уровня абстракции передавать между сокетным слоем и слоем преобразования?

IT>Я опишу возможности сервера, а ты уже смотри сам.

Ты отвечаешь на третий вопрос, а не на второй. Но это ничего.

IT> Данные мы можем принимать в XML-формате, либо напрямую использовать существующую форму посылки сообщения. XML предпочтительнее, т.к. не придётся ничего менять, если изменится форма ввода нового сообщения. Отдавать данные можно тоже в XML'е или в любом другом формате, который будет удобней.

ОК, поиграю с WinInetom и будут форматы.

IT>Мы не можем принимать сообщения в HTML, это должен быть обычный текст. Так же надо будет подумать об аутентификации пользователей.

В сессии аутентифицировать. Тэги запретить или преобразовывать к рсдн-овским, где возможно.

ГС

Здравствуйте Аноним, Вы писали:

IT>>Мы не можем принимать сообщения в HTML, это должен быть обычный текст. Так же надо будет подумать об аутентификации пользователей.

А> В сессии аутентифицировать. Тэги запретить или преобразовывать к рсдн-овским, где возможно.

Лучшый вариант передавать имя и пароль вместе с сообщением. Сессия и кукесы работают не очень стабильно. Вон ты в половине постингов выходишь как аноним

Для этого желательно, чтобы пользователь мог себя идентифицировать на клиенте каким-то образом иначе у нас появится ещё больше "анонимов".

Здравствуйте IT, Вы писали:

IT>Здравствуйте Аноним, Вы писали:

А>> В сессии аутентифицировать. Тэги запретить или преобразовывать к рсдн-овским, где возможно.

IT>Лучшый вариант передавать имя и пароль вместе с сообщением. Сессия и кукесы работают не очень стабильно. Вон ты в половине постингов выходишь как аноним ;)

Не баг, а фича. Это я из дома пишу. Пароль-то у меня шлется на работу.

IT>Для этого желательно, чтобы пользователь мог себя идентифицировать на клиенте каким-то образом иначе у нас появится ещё больше "анонимов".

ОК. Т.е. аутентифицируется пользователь при посылке сообщения в теле сообщения.

Еще вопрос. А таки нам надо WinInet? Вроде XMLHTTP все, что надо обеспечивает. Или там какие-то невидимые миру слезы будут?

Как насчет msgid и номеров сообщений (не зависимых от msgid)? Как насчет присылки сообщения не в том формате, что сейчас? А в каком сейчас? Я, конечно, могу форму перенаправить на локальный IIS, но мне лень.

ГС

Здравствуйте Аноним, Вы писали:

IT>>Лучшый вариант передавать имя и пароль вместе с сообщением. Сессия и кукесы работают не очень стабильно. Вон ты в половине постингов выходишь как аноним

А> Не баг, а фича. Это я из дома пишу. Пароль-то у меня шлется на работу.

Бардак.

Давай свой домашний e-mail, вышлю тебе твой пароль на него.

А> ОК. Т.е. аутентифицируется пользователь при посылке сообщения в теле сообщения.

Точно.

А> Еще вопрос. А таки нам надо WinInet? Вроде XMLHTTP все, что надо обеспечивает. Или там какие-то невидимые миру слезы будут?

Ндо будет про него почитать и если там всё пучком, то можно и XMLHTTP,

А> Как насчет msgid и номеров сообщений (не зависимых от msgid)? Как насчет присылки сообщения не в том формате, что сейчас? А в каком сейчас? Я, конечно, могу форму перенаправить на локальный IIS, но мне лень.

С номерами нет проблем. Сообщения нумеруются сквозняком по всем форумам. Что такое msgid, я не знаю, поясни, плиз. Формат лучше проверять на стороне клиента, т.к., как я уже говорил, кроме скриптов и стандартных COM'ов мы ничего не имеем. Сейчас это обычный HTTP POST с полями, которые ты видишь на форме, но лучше сделать отдельный скрипт.

Здравствуйте IT, Вы писали:

IT>Здравствуйте Аноним, Вы писали:

А>> Еще вопрос. А таки нам надо WinInet? Вроде XMLHTTP все, что надо обеспечивает. Или там какие-то невидимые миру слезы будут?

IT>Ндо будет про него почитать и если там всё пучком, то можно и XMLHTTP,

Казалось бы, вот этого хватает:

    xmlhttp.Open "POST", "http://www.rsdn.ru/forum2nntp.asp", false
    xmlhttp.Send xmldoc 
    Set resp = xmlhttp.responseXML

IT>С номерами нет проблем. Сообщения нумеруются сквозняком по всем форумам.

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

IT>Что такое msgid, я не знаю, поясни, плиз.

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

IT>Формат лучше проверять на стороне клиента, т.к., как я уже говорил, кроме скриптов и стандартных COM'ов мы ничего не имеем. Сейчас это обычный HTTP POST с полями, которые ты видишь на форме, но лучше сделать отдельный скрипт.

Что я должен послать по xmlhttp.Send xmldoc, чтоб статья запостилась?

ГС

Здравствуйте Аноним, Вы писали:

А> Казалось бы, вот этого хватает:

Посмотрим.

А> Т.е. в каждом форуме своя нумерация, но важно, что номера возрастают с возрастанием времени прихода сообщения на сервер. В принципе, может быть одна нумерация на все форумы, но я не уверен.

Нет, нумерация сквозняком по всем форумам, т.е. одна на всех.

IT>>Что такое msgid, я не знаю, поясни, плиз.

А> Уникальный идентификатор. Идея такая, что номера статей на разных серверах могут быть разные, но айди для одной и той же статьи будет один и тот же. Обеспечивается тем, что вырабатывается клиентом и впоследствии переносится с сервера на сервер.

Ok. Надо будет делать для него поддержку, пока этого нет. Добавим.

А> Что я должен послать по xmlhttp.Send xmldoc, чтоб статья запостилась?

Ты это погоди

, пока постить ничего не надо. Тем более лучше сделать один скрипт, который будет принимать данные в XML формате.

Здравствуйте IT, Вы писали:

IT>Нет, нумерация сквозняком по всем форумам, т.е. одна на всех.

ОК, давай пока так попробуем, не меняя.

А>> Что я должен послать по xmlhttp.Send xmldoc, чтоб статья запостилась?

IT>Ты это погоди :wow: , пока постить ничего не надо.

А что такое? Все равно при постинге проверяются креденшиалз, так что если кто захочет пошутить, то сделает это ограниченное число раз. Пролема в другом — я, тупенький, не понимаю, что происходит в 80-м порту, когда делается xmlhttp.Send xmldoc. Не понимаю я также, как из серверного ASP посмотреть что бы то ни было присланнное по xmlhttp.Send xmldoc.

IT>Тем более лучше сделать один скрипт, который будет принимать данные в XML формате.

Изложи идею поподробнее. Как посылать? Какой формат тебе посылать? На первом этапе должно хватать
1) команда — LIST
ответ — список имеющихся групп, с интервалами доступных номеров статей.
2) команда — GROUP <группа>
ответ — интервал статей
3) команда — ARTICLE <номер статьи>
ответ — статья

ГС

Здравствуйте George_Seryakov, Вы писали:

GS>Значит, так:

GS>Сокетный интерфейс я... спрототипировал. И теперь нуждаюсь в совете. Даже в двух.

GS>Приложение естественно разбивается на две части — 1) сокетную часть с паралеллизмом, ивентами и довольно низкоуровневым программированием. И 2) преобразователь данных, который будет взамодействовать с форумом и отдавать данные сокетной части для передачи. Вторую часть, вроде, неплохо сделать КОМ-сервером (первая уже сервис), сменным под разние форумы на разных сайтах.

1. А почему первая уже сервис? Еще довольно много клиентов под Win9x осталось, как они этот сервис запустят?
2. Сменный КОМ-сервер не обязательно, достаточно предусмотреть хороший XML-based интерфейс взаимодействия и некоторую конфигурабельность слоя преобразователя.

GS>Первый вопрос такой: на каком языке естественно писать слой обработки данных?
Однозначно С++. И можешь спокойно юзать XMLHTTP, а лучше ServerXMLHTTP — он надежнее, и вообще весь MSXML3.0 тебе понадобиться. Просто не на C++ этот пакет сильно раздует в размерах ;-)

GS>Второй вопрос: Данные какого уровня абстракции передавать между сокетным слоем и слоем преобразования?
Данные с сервера приходят в XML (формально), фактически они могут ити и в NNTP. Нам все равно в каком из текстовых протоколов посылать данные, главное чтоб по HTTP, а по HTTP можно передать что угодно. Например так:
<response>
215 list of newsgroups follows

rsdn.rsdn 6717 223 y
..........
.
</response>
Вообще можно на чистом NNTP: клиент передает NNTP через HTTP POST и получает NNTP ответ тоже по HTTP. На клиенте можно вообще убрать всякий разбор сообщений и т.п. Выбросить MSXML и юзать WinInet, тогда клиент будет совсем легким и скачивать его будет не напряжно.
Игорь, прочитай RFC 977 чтоб понимать о чем разговор.

Здравствуйте IT, Вы писали:

IT>Здравствуйте George_Seryakov, Вы писали:

GS>>Первый вопрос такой: на каком языке естественно писать слой обработки данных?

IT>Давай C++, с #import там всё не немного сложнее васика.

GS>>Второй вопрос: Данные какого уровня абстракции передавать между сокетным слоем и слоем преобразования?

IT>Я опишу возможности сервера, а ты уже смотри сам.
IT>На сервере мы не можем запускать ничего кроме скриптов и стандартных COM-объектов.
На самом деле мы можем писать свои расширения и CGI-exeшники, ASP, Perl, PHP, ColdFusion и др., короче полный комплект. А вот с КОМ-ом и фильтрами действительно туго.

Здравствуйте Аноним, Вы писали:

А>Здравствуйте IT, Вы писали:

IT>>Здравствуйте Аноним, Вы писали:

А>>> В сессии аутентифицировать. Тэги запретить или преобразовывать к рсдн-овским, где возможно.

IT>>Лучшый вариант передавать имя и пароль вместе с сообщением. Сессия и кукесы работают не очень стабильно. Вон ты в половине постингов выходишь как аноним ;)
Вот это интересный вопрос. Например ОЕ поддерживает аутентификацию по NNTP, но в RFC про это ничего не написано. Кто знает как оно реализовано?

А> Не баг, а фича. Это я из дома пишу. Пароль-то у меня шлется на работу.

IT>>Для этого желательно, чтобы пользователь мог себя идентифицировать на клиенте каким-то образом иначе у нас появится ещё больше "анонимов".

А> ОК. Т.е. аутентифицируется пользователь при посылке сообщения в теле сообщения.
Тут не все так просто. NNTP работает на базе сессий, причем сессии эти реализованы удержанием соединения (ну что поделать, старенький это протокол). Тут есть два варианта обхода:
1. (предпочтительный) Работа с сессиями эмулируется на клиенте (проксе). Т.е. например на команды LAST и т.п. клиент ничего не посылает на сервер, а просто ставит себе на заметку. Все данные (включая имя и пароль) посылаются при запросе. Имя и пароль вводятся в настройках клиента.
2. Клиент просто помнит сессионные (ASP-шные) кукисы, а вся работа реализуется на базе ASP-шных сессий. Логон происходит один раз вначале работы клиента с сервером. У этого способа есть плюсы и минусы. Минус — привязка к ASP технологии (это если кто захочет продавать/распространять эту штуку потом :-) )

А> Еще вопрос. А таки нам надо WinInet? Вроде XMLHTTP все, что надо обеспечивает. Или там какие-то невидимые миру слезы будут?
Лучше WinInet, так ты облегчишь клиента минимум на 600кб.

А> Как насчет msgid и номеров сообщений (не зависимых от msgid)? Как насчет присылки сообщения не в том формате, что сейчас? А в каком сейчас? Я, конечно, могу форму перенаправить на локальный IIS, но мне лень.
msgid генерится на клиенте и запоминается в нашей БД. Соотв поле в БД нужно будет добавить (и сгенерировать msgid для уже существующих сообщений). А еще не забыть генерацию этих msgid при отправке через веб :-)

Здравствуйте Аноним, Вы писали:

А>Здравствуйте IT, Вы писали:

IT>>Здравствуйте Аноним, Вы писали:

А>>> Еще вопрос. А таки нам надо WinInet? Вроде XMLHTTP все, что надо обеспечивает. Или там какие-то невидимые миру слезы будут?

IT>>Ндо будет про него почитать и если там всё пучком, то можно и XMLHTTP,

А> Казалось бы, вот этого хватает:

А>

А>    xmlhttp.Open "POST", "http://www.rsdn.ru/forum2nntp.asp", false
А>    xmlhttp.Send xmldoc 
А>    Set resp = xmlhttp.responseXML
А>

:-(

IT>>С номерами нет проблем. Сообщения нумеруются сквозняком по всем форумам.

А> Т.е. в каждом форуме своя нумерация, но важно, что номера возрастают с возрастанием времени прихода сообщения на сервер. В принципе, может быть одна нумерация на все форумы, но я не уверен.

Сейчас нумерация _сквозная_. Т.е. в каждой группе номерной ряд имеет разрывы. Это потому что мы вообще собирались отказаться от групп и ввести фильтры. Вот тебе еще одна проблема — NNTP клиент предполагает неразрывную нумерацию.

IT>>Что такое msgid, я не знаю, поясни, плиз.

А> Уникальный идентификатор. Идея такая, что номера статей на разных серверах могут быть разные, но айди для одной и той же статьи будет один и тот же. Обеспечивается тем, что вырабатывается клиентом и впоследствии переносится с сервера на сервер.

IT>>Формат лучше проверять на стороне клиента, т.к., как я уже говорил, кроме скриптов и стандартных COM'ов мы ничего не имеем. Сейчас это обычный HTTP POST с полями, которые ты видишь на форме, но лучше сделать отдельный скрипт.
Сообщения посылаются через HTTP POST в том формате, как они идут от клиента (т.е. NNTP).
2Игорь: Читать CDO for W2K, а в особенности IMessage.GetStream, ADODB.Stream.
Схема такая:
Клиент постит сообщение как обычно (NNTP), на сервер оно попадает обернутое в HTTP POST, оттуда в CDO.GetStream->Flush, дальше методами CDO разбирается и пихается в базу.
При отдаче клиенту наоборот — CDO формирует сообщение, затем CDO.GetStream и в Response.BinaryWrite.
Зачем так сложно? А ты хочешь разбираться с разными кодировками, MIME, UUEncode, base64 и т.п вручную?

А> Что я должен послать по xmlhttp.Send xmldoc, чтоб статья запостилась?
Сообщение в NNTP.
А теперь самое веселое. Что будем делать, когда юзеры захотят постить месаги в HTML формате, присылать аттачменты, прилеплять картинки и т.п? :wow:

Здравствуйте Slov, Вы писали:

GS>>Сокетный интерфейс я... спрототипировал. И теперь нуждаюсь в совете. Даже в двух.

GS>>Приложение естественно разбивается на две части — 1) сокетную часть с паралеллизмом, ивентами и довольно низкоуровневым программированием. И 2) преобразователь данных, который будет взамодействовать с форумом и отдавать данные сокетной части для передачи. Вторую часть, вроде, неплохо сделать КОМ-сервером (первая уже сервис), сменным под разние форумы на разных сайтах.

S>1. А почему первая уже сервис? Еще довольно много клиентов под Win9x осталось, как они этот сервис запустят?

Как приложение, например.

S>2. Сменный КОМ-сервер не обязательно, достаточно предусмотреть хороший XML-based интерфейс взаимодействия и некоторую конфигурабельность слоя преобразователя.

Если делать, как ты предлагаешь — весь разбор NNTP данных на сервере — то никаких сменных модулей не надо.

GS>>Первый вопрос такой: на каком языке естественно писать слой обработки данных?
S>Однозначно С++. И можешь спокойно юзать XMLHTTP, а лучше ServerXMLHTTP — он надежнее, и вообще весь MSXML3.0 тебе понадобиться. Просто не на C++ этот пакет сильно раздует в размерах

Принято.

GS>>Второй вопрос: Данные какого уровня абстракции передавать между сокетным слоем и слоем преобразования?
S>Данные с сервера приходят в XML (формально), фактически они могут ити и в NNTP. Нам все равно в каком из текстовых протоколов посылать данные, главное чтоб по HTTP, а по HTTP можно передать что угодно. Например так:
S><response>
S>215 list of newsgroups follows

S>rsdn.rsdn 6717 223 y
S>..........
S>.
S></response>
S>Вообще можно на чистом NNTP: клиент передает NNTP через HTTP POST и получает NNTP ответ тоже по HTTP. На клиенте можно вообще убрать всякий разбор сообщений и т.п. Выбросить MSXML и юзать WinInet, тогда клиент будет совсем легким и скачивать его будет не напряжно.

Не проблема. Т.е. предлагается такое решение: 1) никакого разбора на клиенте, 1.1) Никого слоя преобразования, 2) паковка NNTP в HTTP, 3) весь разбор и реализация логики NNTP на сервере. Пункт 3 я сделать не смогу, вы его беретесь сделать?

В таком разе XML мне без надобности, надо канализировать NNTP голым WinInet-ом, принимается.

А как мне в серверном скрипте посмотреть переданные данные? Если я POST-ом все NNTP-шные команды шлю? без никакой обертки?

S>Игорь, прочитай RFC 977 чтоб понимать о чем разговор.

А также 2980 и 1036.

Здравствуйте Slov, Вы писали:

S>Вот это интересный вопрос. Например ОЕ поддерживает аутентификацию по NNTP, но в RFC про это ничего не написано. Кто знает как оно реализовано?

AUTHINFO, поди. rfc 2980. Я в состоянии оттрассировать NNTP, но до аутентификации еще не дошел.

А>> ОК. Т.е. аутентифицируется пользователь при посылке сообщения в теле сообщения.
S>Тут не все так просто. NNTP работает на базе сессий, причем сессии эти реализованы удержанием соединения (ну что поделать, старенький это протокол). Тут есть два варианта обхода:
S>1. (предпочтительный) Работа с сессиями эмулируется на клиенте (проксе). Т.е. например на команды LAST и т.п. клиент ничего не посылает на сервер, а просто ставит себе на заметку. Все данные (включая имя и пароль) посылаются при запросе. Имя и пароль вводятся в настройках клиента.

Т.е. протокол расширятеся на аутентификацию при каждом запросе.

S>2. Клиент просто помнит сессионные (ASP-шные) кукисы, а вся работа реализуется на базе ASP-шных сессий. Логон происходит один раз вначале работы клиента с сервером. У этого способа есть плюсы и минусы. Минус — привязка к ASP технологии (это если кто захочет продавать/распространять эту штуку потом

)

Т.е при каждом запросе на сервер он будет спрашивать куку? Тоже можно, но надо мне обхяснить, как с куками работать.

А>> Еще вопрос. А таки нам надо WinInet? Вроде XMLHTTP все, что надо обеспечивает. Или там какие-то невидимые миру слезы будут?
S>Лучше WinInet, так ты облегчишь клиента минимум на 600кб.

Если мы доклеиваем к каждому NNTP сообщению сессионную информацию (логон, текушая группа, мессадж), то надо бы XML. Или нет?

S>msgid генерится на клиенте и запоминается в нашей БД. Соотв поле в БД нужно будет добавить (и сгенерировать msgid для уже существующих сообщений). А еще не забыть генерацию этих msgid при отправке через веб

Пока есть только чтение, можно считать, что msgid == номер.

Здравствуйте Slov, Вы писали:

S>Здравствуйте Аноним, Вы писали:

А>> Казалось бы, вот этого хватает:

А>>    xmlhttp.Open "POST", "http://www.rsdn.ru/forum2nntp.asp", false
А>>    xmlhttp.Send xmldoc 
А>>    Set resp = xmlhttp.responseXML

Но как все-таки мерзко выглядит программирование XML-я на голых плюсах. Да и на ВБ не лучше.

S>Сейчас нумерация _сквозная_. Т.е. в каждой группе номерной ряд имеет разрывы. Это потому что мы вообще собирались отказаться от групп и ввести фильтры. Вот тебе еще одна проблема — NNTP клиент предполагает неразрывную нумерацию.

Вот не нашел в стандарте такого, более того — должна же быть предусмотрена возможность для отработки cancel. Можно будет легко проверить — как OE реагирует на разрывы в последовательности.

S>Сообщения посылаются через HTTP POST в том формате, как они идут от клиента (т.е. NNTP).
S>2Игорь: Читать CDO for W2K, а в особенности IMessage.GetStream, ADODB.Stream.
S>Схема такая:
S>Клиент постит сообщение как обычно (NNTP), на сервер оно попадает обернутое в HTTP POST, оттуда в CDO.GetStream->Flush, дальше методами CDO разбирается и пихается в базу.
S>При отдаче клиенту наоборот — CDO формирует сообщение, затем CDO.GetStream и в Response.BinaryWrite.
S>Зачем так сложно? А ты хочешь разбираться с разными кодировками, MIME, UUEncode, base64 и т.п вручную?

А>> Что я должен послать по xmlhttp.Send xmldoc, чтоб статья запостилась?
S>Сообщение в NNTP.

Аутентификация? Текущая группа,номер?

S>А теперь самое веселое. Что будем делать, когда юзеры захотят постить месаги в HTML формате, присылать аттачменты, прилеплять картинки и т.п?

А ЮЮки на что?

Здравствуйте George_Seryakov, Вы писали:

S>>2. Сменный КОМ-сервер не обязательно, достаточно предусмотреть хороший XML-based интерфейс взаимодействия и некоторую конфигурабельность слоя преобразователя.

GS> Если делать, как ты предлагаешь — весь разбор NNTP данных на сервере — то никаких сменных модулей не надо.
Просто я писал и по ходу дела додумывал :-)

GS>
GS>Не проблема. Т.е. предлагается такое решение: 1) никакого разбора на клиенте, 1.1) Никого слоя преобразования, 2) паковка NNTP в HTTP, 3) весь разбор и реализация логики NNTP на сервере. Пункт 3 я сделать не смогу, вы его беретесь сделать?
Нужно будет поставить эксперимент. Если CDO for W2K удачно разберет месагу для NNTP (она чем-то от обычной почтовой отличается?), то на сервере это будет легче делать. А вот если нет, то ой...

GS>В таком разе XML мне без надобности, надо канализировать NNTP голым WinInet-ом, принимается.
Угу.

GS>А как мне в серверном скрипте посмотреть переданные данные? Если я POST-ом все NNTP-шные команды шлю? без никакой обертки?
Request.Form
И поставь себе Visual InterDev или VS.NET, если хочешь ASP отлаживать.

Здравствуйте George_Seryakov, Вы писали:

GS>Здравствуйте Slov, Вы писали:

S>>Вот это интересный вопрос. Например ОЕ поддерживает аутентификацию по NNTP, но в RFC про это ничего не написано. Кто знает как оно реализовано?

GS>AUTHINFO, поди. rfc 2980. Я в состоянии оттрассировать NNTP, но до аутентификации еще не дошел.
В двух словах расскажи, а то влом лезть.

S>>2. Клиент просто помнит сессионные (ASP-шные) кукисы, а вся работа реализуется на базе ASP-шных сессий. Логон происходит один раз вначале работы клиента с сервером. У этого способа есть плюсы и минусы. Минус — привязка к ASP технологии (это если кто захочет продавать/распространять эту штуку потом :-) )

GS> Т.е при каждом запросе на сервер он будет спрашивать куку? Тоже можно, но надо мне обхяснить, как с куками работать.

Я подумал. Лучше вариант №2.
Никто никого не спрашивает. Попробуй оттрасировать HTTP при _первом_ обращении к ASP. Когда ты подключишься первый раз ты получишь куку. Ее нужно запомнить и передавать потом при каждом запросе на сервер. Если получаешь новую куку — запоминаешь ее и т.д. Кука — это просто HTTP заголовок Cookie, Set-Cookie и т.д. Номер RFC не помню, но не тот где HTTP.

Какой статус сообщает NNTP клиенту что нужен пароль?

А>>> Еще вопрос. А таки нам надо WinInet? Вроде XMLHTTP все, что надо обеспечивает. Или там какие-то невидимые миру слезы будут?
S>>Лучше WinInet, так ты облегчишь клиента минимум на 600кб.

GS> Если мы доклеиваем к каждому NNTP сообщению сессионную информацию (логон, текушая группа, мессадж), то надо бы XML. Или нет?

Если по варианту 2, то не надо.

S>>msgid генерится на клиенте и запоминается в нашей БД. Соотв поле в БД нужно будет добавить (и сгенерировать msgid для уже существующих сообщений). А еще не забыть генерацию этих msgid при отправке через веб :-)

GS> Пока есть только чтение, можно считать, что msgid == номер.
const="(Some GUID)@rsdn.ru";
msgid=номер+const;

Здравствуйте George_Seryakov, Вы писали:

GS> Но как все-таки мерзко выглядит программирование XML-я на голых плюсах. Да и на ВБ не лучше.
Короче, покажи свою проксю.

S>>Сейчас нумерация _сквозная_. Т.е. в каждой группе номерной ряд имеет разрывы. Это потому что мы вообще собирались отказаться от групп и ввести фильтры. Вот тебе еще одна проблема — NNTP клиент предполагает неразрывную нумерацию.

GS> Вот не нашел в стандарте такого, более того — должна же быть предусмотрена возможность для отработки cancel. Можно будет легко проверить — как OE реагирует на разрывы в последовательности.
Ну, будем надеяться :-)

S>>Сообщения посылаются через HTTP POST в том формате, как они идут от клиента (т.е. NNTP).
S>>2Игорь: Читать CDO for W2K, а в особенности IMessage.GetStream, ADODB.Stream.
S>>Схема такая:
S>>Клиент постит сообщение как обычно (NNTP), на сервер оно попадает обернутое в HTTP POST, оттуда в CDO.GetStream->Flush, дальше методами CDO разбирается и пихается в базу.
S>>При отдаче клиенту наоборот — CDO формирует сообщение, затем CDO.GetStream и в Response.BinaryWrite.
S>>Зачем так сложно? А ты хочешь разбираться с разными кодировками, MIME, UUEncode, base64 и т.п вручную?

А>>> Что я должен послать по xmlhttp.Send xmldoc, чтоб статья запостилась?
S>>Сообщение в NNTP.

GS> Аутентификация? Текущая группа,номер?

S>>А теперь самое веселое. Что будем делать, когда юзеры захотят постить месаги в HTML формате, присылать аттачменты, прилеплять картинки и т.п? :wow:

GS>А ЮЮки на что?
А причем тут к перечисленному UUE? Это ж не фидо.
Не, теоретически все это тоже реализуемо, но практически ... нафик.

Здравствуйте Slov, Вы писали:

GS>>Не проблема. Т.е. предлагается такое решение: 1) никакого разбора на клиенте, 1.1) Никого слоя преобразования, 2) паковка NNTP в HTTP, 3) весь разбор и реализация логики NNTP на сервере. Пункт 3 я сделать не смогу, вы его беретесь сделать?

S>Нужно будет поставить эксперимент. Если CDO for W2K удачно разберет месагу для NNTP (она чем-то от обычной почтовой отличается?), то на сервере это будет легче делать. А вот если нет, то ой...

ОК. Убираю XMLHTTP, пихаю WinInet. Еще там куки обработать...

GS>>В таком разе XML мне без надобности, надо канализировать NNTP голым WinInet-ом, принимается.
S>Угу.

GS>>А как мне в серверном скрипте посмотреть переданные данные? Если я POST-ом все NNTP-шные команды шлю? без никакой обертки?
S>Request.Form

Убедил. А мне постом вам данные слать?

S>И поставь себе Visual InterDev или VS.NET, если хочешь ASP отлаживать.

Дык стоит. Я даже умею ASP отлажывать, точнее, умел, сейчас лениво систему настраивать. Как посмотреть элементы формы — знаю.

Здравствуйте Slov, Вы писали:

GS>>AUTHINFO, поди. rfc 2980. Я в состоянии оттрассировать NNTP, но до аутентификации еще не дошел.
S>В двух словах расскажи, а то влом лезть.

Там много чего написано, но OE делает так:

-> AUTHINFO USER username
<- 381 Authoriszation required
-> AUTHINFO PASS password
<- 281 Authoriszation accepted

Когда пароль не нужен, отвечает сразу кодом 281, до пароля. Если неверный — 502. Есть еще PAP запрос, но я не смотрел, как там.

S>Никто никого не спрашивает. Попробуй оттрасировать HTTP при _первом_ обращении к ASP. Когда ты подключишься первый раз ты получишь куку. Ее нужно запомнить и передавать потом при каждом запросе на сервер. Если получаешь новую куку — запоминаешь ее и т.д. Кука — это просто HTTP заголовок Cookie, Set-Cookie и т.д. Номер RFC не помню, но не тот где HTTP.

Пошел читать RTFM. Это что, мне текст слов вручную парсить в поисках куки?

S>Какой статус сообщает NNTP клиенту что нужен пароль?

По идее это в ОЭ должно выставляться. Протоко предусматривает напоминание, но ОЭ его, скорее всего, не обрабатывает.

Здравствуйте Slov, Вы писали:

S>Нужно будет поставить эксперимент. Если CDO for W2K удачно разберет месагу для NNTP (она чем-то от обычной почтовой отличается?),

Вроде, не очень. В принципе, юзнетная мессага может быть послана по обчной почте.
Поле group там в заголовке должно нас волновать. Может быть, references. Всякие dictribution, approval, followup-to — игнорировать.

Здравствуйте George_Seryakov, Вы писали:

GS> Там много чего написано, но OE делает так:

->> AUTHINFO USER username
GS><- 381 Authoriszation required
->> AUTHINFO PASS password
GS><- 281 Authoriszation accepted

GS> Когда пароль не нужен, отвечает сразу кодом 281, до пароля. Если неверный — 502. Есть еще PAP запрос, но я не смотрел, как там.

Короче, можешь привести пример общения ОЕ с сервером включая авторизацию? Лучше если пример будет с вариантами и т.п. Да, и в своей проксе убери КОМ и сделай как я говорил — все запросы от ОЕ передаешь через HTTP POST в исходном виде, ответ получаешь прямо документом Content-Type: text/plain короче тупая прокся (но не забудь про сессионную куку).

Здравствуйте Slov, Вы писали:

S>Короче, можешь привести пример общения ОЕ с сервером включая авторизацию? Лучше если пример будет с вариантами и т.п.

Сейчас — нет. Это проблема написания тупого ответчика, будет решена при отладке прокси. Посколько прокси мы переписываем на WinInet, которого я не знаю, все это затягивается.

S>Да, и в своей проксе убери КОМ и сделай как я говорил — все запросы от ОЕ передаешь через HTTP POST в исходном виде, ответ получаешь прямо документом Content-Type: text/plain короче тупая прокся (но не забудь про сессионную куку).

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

Здравствуйте George_Seryakov, Вы писали:

GS>Читаю WinInet, ждите. Либо пришлите работающий кусок кода с примером использования WinInet нужным мне способом. А то все эти хендлы, флаги и контексты в глазах так и рябят. А тут еще тикет и каминное стекло разбилось...
http://www.rsdn.ru/article/?inet/wininet.xml
Это подойдет?

Там как раз и класс неплохой имеется

Здравствуйте Slov, Вы писали:

S>Здравствуйте George_Seryakov, Вы писали:

GS>>Читаю WinInet, ждите. Либо пришлите работающий кусок кода с примером использования WinInet нужным мне способом. А то все эти хендлы, флаги и контексты в глазах так и рябят. А тут еще тикет и каминное стекло разбилось...
S>http://www.rsdn.ru/article/?inet/wininet.xml
S>Это подойдет?

Подойдет. А вот еще есть у меня такое подозрение, что XMLHTTP перекрывает wininet для большинства неизвратных случаев.

S>Там как раз и класс неплохой имеется

Класс правильный. (Правильный класс при создании должен делать почти большую часть (в идеале — всю) работу.)

ГС

	От:	Mikl
	Дата:	11.11.01 02:18
	Оценка:	2 (1)

От:	IT	linq2db.com
Дата:	11.11.01 02:48
Оценка:

	От:	Аноним
	Дата:	12.11.01 00:09
	Оценка:

От:	IT	linq2db.com
Дата:	12.11.01 00:30
Оценка:

	От:	Аноним
	Дата:	12.11.01 00:53
	Оценка:

	От:	George_Seryakov
	Дата:	12.11.01 13:35
	Оценка:

От:	adontz	http://adontz.wordpress.com/
Дата:	23.11.01 19:47
Оценка:

От:	Slov	http://www.helicontech.com
Дата:	03.01.02 13:12
Оценка: