Каморка

vg,

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

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

В виду моей "дремучести" в вопросах firiwall, proxy etc., у меня были (и остаются) большие опасения, что нужно будет писать custom code под каждый тип firewall. Т.е. если преполжить, что абсолютно все firewall/proxy ,будут поддерживать код написанный для SOCKS4, то жизнь становится гораздо легче. Так ли это на самом деле?

Еслит нет, то я бы предпочел написать что-то типа automation client для IE, который каждый час будет запускать Explorer, идти на соответствующий сайт, заполнять формочку и кликать "submit". В этом случае меня тип firewall не интересует совсем. Достаточно. чтобы IE был один раз сконфигурирован для proxy.
Да и дилог с кастомерами сильно упроститься. Требование "allow submitting html forms from IE" должно быть понятно менеджеру любого уровня. Смогли сконфигурировать IE для работы с proxy - хорошо, нет - извините, будем dial-up использовать как раньше.

Чисто идеологически, предпочел бы использовать HTTP, SOAP или что нибудь аналогичное, высокоуровневое, позволяющее абстрагироваться от транспортного уровня.
К сожалению пропагандисты протоколов высокого уровня, в ответ на мой постиг отделывались обещанием написать все за 1 день, 3 час (кто быстрее) и не выдавали никакой конкретики.

Нафига нужен SOAP при передаче неструктурированных логов?
От транспортного уровня, в данной ситуации всё равно не абстрагироваться, по причине security requirements.
Сначала надо определится что можно, а что нет, а потом уже плясать от возможностей.
Кстати, можно поробовать Perl использовать, он как раз для работы с файлам очень даже ничего, да и HTTP POST из него делать можно.
Идея с IE automation тоже неплоха, я так думаю всё можно будет через WSH скрипты написать...


ЗЫ Все firewalls прозрачны(ну или нет ) по определению, не ломайте голову

я бы поставил на клиенте фигню, которая бы паковала и на хардкоденый HTTPS сервак отправляла бы. и нефиг муму изобретать

leonid,

Спасибо большое за поддержку и за код. Всегда приятнее иметь дело с кодом (с псевдо кодом на худой конец)

Совершенно не за что. Про код согласен. Сам терпеть не навижу, болтовню без кода, или его фрагментов.

, чем слушать общания гуру написать это за 3 часа.

Те два маньяка, что чуть выше пропостили - на самом деле хорошие спецы (2Папа, и 2Мармот - спокойне товарищи, спокойнее. не надо волноваться. Это не наезд на вас). Только ленивые они, имхо. Но код, думаю, особенно для HTTP - пропостить могут.

В виду моей "дремучести" в вопросах firiwall, proxy etc., у меня были (и остаются) большие опасения, что нужно будет писать custom code под каждый тип firewall. Т.е. если преполжить, что абсолютно все firewall/proxy ,будут поддерживать код написанный для SOCKS4, то жизнь становится гораздо легче. Так ли это на самом деле?

Ни сколько не хочу и не могу Вас здесь убеждать. Ибо моё мнение может принести вред Вашему делу (я не знаю ни особенностей Вашей "клиентуры", да и самого проекта). Главный принцип - не навреди. Конечно, у Вас не должно оставаться сомнений, когда решение будет принятто. Могу сказать только следующее:

1) Я на самом деле считаю, что большинство как промышленных, так и самодельных фаревалов должны поддерживать SOCKS 4. Это связано с тем, что производитель межсетевого экрана должен обеспечивать работу старых клиентов, ориентированных на SOCKS 4. Если этого не далать, то часть клиентуры (со старым клиентским ПО) будет просто потеряна. Даже MS решения (как MS Proxy 2.0, так и MS ISA Server 2000) поддерживают SOCKS 4. И я не вижу причины, по которой это былоб нельзя делать большинству производителей.
Хотя было бы ошибкой с моей стороны выдавать это за данность.

2) SOCKS 5 - не намного сложнее SOCKS 4. Там введена возможность нормальной аутинтификации и поддержка UDP ( SOCKS 4 держал только TCP, если правильно помню). Но думаю ни то, ни другое - по сути в Вашей задаче не понадобится. Поэтому, значительного усложнения кода + к тому, что я пропотил в примере smtp - там не будет. Про SOCKS 5 можно прочитать здесь - http://www.socks.permeo.com (включая rfc и faq)
Пример кода можно посмотреть здесь http://www.sources.ru/cpp/cpp_csocksifiedsocket.shtml
Не самый лучший, конечно. Убейте там всё, что связано с MFC. Оставьте только то, что связано с SOCKS 5. Сделайте всё на обычном winsock API.

3) Если бы я строил такого клиента, то я бы писал с учётом трёх основных случаев: direct access; SOCKS 4; SOCKS 5.
Cнабдил его (клиента) возможностью нехитрого конфигурирования, даже в из текстового файла. Где бы и писал, какой из этих трёх вариантов надо использовать. Причём direct access - понятие было б относильно широкое, поскольку "захватывало б" и NAT, и непосредственно direct access, и случаи со специфическими "клиентами", на хостах юзверей, например, т.н. Firewall Client для изделий MS.

Еслит нет, то я бы предпочел написать что-то типа automation client для IE, который каждый час будет запускать Explorer, идти на соответствующий сайт, заполнять формочку и кликать "submit". В этом случае меня тип firewall не интересует совсем. Достаточно. чтобы IE был один раз сконфигурирован для proxy.
Да и дилог с кастомерами сильно упроститься. Требование "allow submitting html forms from IE" должно быть понятно менеджеру любого уровня. Смогли сконфигурировать IE для работы с proxy - хорошо, нет - извините, будем dial-up использовать как раньше.

Я уже постил раньше, что считаю это хорошей Вашей идеей. Единтсвенное, куда бы я покурил, так это в сторону того, чтобы делать это не собственно из IE, а из проги, написанной, например, на С/C++ и работающей по HTTP. Т.е. так, чтобы пользователь даже и не нажимал "... и кликать "submit"...". При этом можно былоб или писать всё руками (на мой взгляд предпочтительнее), или использовать COM того же IE (с COM IE я только игрался очень давно. путного ничего не писал). Это бы работало автоматически.

Ну, а если пользователь может в здравом уме кликать "submit", и это допустимо (такой "неавтоматизм"), то я не понимаю, в чём проблема? Заходим на Ваш сайт, делаем копи/паст в окошечко формы, кликаем "submit". Именно по такой схеме обновляются новостные разделы на некоторых российских www-корпоративных ресурсах. Говорю так уверенно, потому, как знаю про те ресурсы.

Чисто идеологически, предпочел бы использовать HTTP, SOAP или что нибудь аналогичное, высокоуровневое, позволяющее абстрагироваться от транспортного уровня.

Marmot здесь прав про SOAP. Курить надо в сторону HTTP.

2Marmot,

Нафига нужен SOAP при передаче неструктурированных логов?

Верно.

От транспортного уровня, в данной ситуации всё равно не абстрагироваться, по причине security requirements.

Непонятно, что Вы имеете здесь ввиду? Транспорт - транспортом, security - security-ей.

Кстати, можно поробовать Perl использовать, он как раз для работы с файлам очень даже ничего, да и HTTP POST из него делать можно.

Почему Perl? Из VB или C HTTP POST нельзя? И потом, будет Perl-ов код работать на клиенте W2kProf у leonid - a? Вернее на хостах W2kProf клиентских контор leonid-а. Я просто не знаю, вот и спрашиваю. Это не под**ка.

leonid писал(а):vg,

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

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

В виду моей "дремучести" в вопросах firiwall, proxy etc., у меня были (и остаются) большие опасения, что нужно будет писать custom code под каждый тип firewall. Т.е. если преполжить, что абсолютно все firewall/proxy ,будут поддерживать код написанный для SOCKS4, то жизнь становится гораздо легче. Так ли это на самом деле?

Еслит нет, то я бы предпочел написать что-то типа automation client для IE, который каждый час будет запускать Explorer, идти на соответствующий сайт, заполнять формочку и кликать "submit". В этом случае меня тип firewall не интересует совсем. Достаточно. чтобы IE был один раз сконфигурирован для proxy.
Да и дилог с кастомерами сильно упроститься. Требование "allow submitting html forms from IE" должно быть понятно менеджеру любого уровня. Смогли сконфигурировать IE для работы с proxy - хорошо, нет - извините, будем dial-up использовать как раньше.

Чисто идеологически, предпочел бы использовать HTTP, SOAP или что нибудь аналогичное, высокоуровневое, позволяющее абстрагироваться от транспортного уровня.
К сожалению пропагандисты протоколов высокого уровня, в ответ на мой постиг отделывались обещанием написать все за 1 день, 3 час (кто быстрее) и не выдавали никакой конкретики.

слушай, если тебе лениво в гугле набрать 2 слова так и скажы, и не нада тут красивыми словами кидатся.
ты спрашивал про решение а не про код, если бы ты сказал что мол пацаны немогу разобраться как выложить файл на секюрный сервак или еще чего...

2vg and all

1. Ну зачем обсуждать Winsock и SOCKS? для этой задачи это слишком низкий уровень!
2vg, я конечно понимаю, что вам хочется похвастаться знаниями, нo надо и меру знать.

2. Транспорт завязан на security по причине неообходимости открытия портов, например если 20/21 закрыты, то ftp уже не годится.

3. Если хочется писать на С/С++, не забывайте про WinINet

4. Почему Perl? Да потому, что он хорошо работает с файлами типа логов, гораздо удобнее чем VB, интерпретатор можно и поставить.
Хотя конечно, тут я немного не подумал, привык считать что логи обычно на серваках

5. Решил я тут поискать, не делал ли кто что нибудь похожего и нашёл вот это : http://www.w3.org/ComLine/User/CommandLine.html
Компилированный бинарник берут вот тут http://www.w3.org/Library/Distribution/ ... V5.4.0.exe
Осталось вставить это в простенький скрипт и вперёд , постить файлы через HTTP прямо из коммандной строки...

2Marmot,

2vg and all
1. Ну зачем обсуждать Winsock и SOCKS? для этой задачи это слишком низкий уровень!

Я постил только своё мнения. При этом я не отрицал других подходов. Напротив, я постил, чтоб leonid посмотрел другие решения.

2vg, я конечно понимаю, что вам хочется похвастаться знаниями, нo надо и меру знать.

Marmot, мне неприятно и непонятно откуда у Вас сложилось такое мнение. Тем более, что Вы знаете моё отношение к Вашему мнению.

Хвастаться мне не зачем. Я знаю и цену себе и одновременно свою безграмотность во многих вопросах.
От ложного чувства "признания", "не признания" в определённых кругах нет никакого прока. На этом форуме точно - мне не зачем показывать здесь свои знания, т.к. ни бублик, ни пирожок мне не дадут. Всё очень просто - могут дать бублик, значит можно нечто демонстрировать. Не могут дать бублик - влом даже на клавиши нажимать для хвастовства.
Должна быть логика и последовательность во всём. В том, что я говорю есть логика (про бублик). В том, что Вы говорите нет логики, т.е. я выразился профессиональным языком - и это означает мою заносчивость? Ну бред, ведь.

Да и вообще, о каких-таких знаниях Вы говорите? Какой-такой низкий уровень, требующих "особых" знаний, которыми можно было бы похвастаться? Winsock и SOCKS? Хотите верьте, хотите нет - это уровень джуниора. Посмотрите на форумы профессионалов-программеров в России. Там только заикнись, мол, Winsock и SOCKS - вот, что я, сама крутость, знаю. Так дадут, что мало не покажется.
Лично я и близко бы программера-сетевика не взял бы на работу без этих джуниор знаний. У меня в отделе мои подчинённые, бабушки, которым за полтиник, с Winsock знакомы. А Вы говорите, что я заношусь. Ну, давайте тогда говорить, что демонстрация знаний того, где находится кнопка включения компьютера - это тоже хвастовство.

2. Транспорт завязан на security по причине неообходимости открытия портов, например если 20/21 закрыты, то ftp уже не годится.

Имеет отношение к обеспечению инф. безопасноти, но только как одна из составляющих, и очень небольшая по объёму работ.
(говорю буквально о том, что сказали Вы). Я бы не ставил знак равенства между обеспечением фильтрации трафика и обеспечением инф. безопасности.

3. Если хочется писать на С/С++, не забывайте про WinINet

Этим пользуются дети. Или когда программер поставлен в такие условия. Профи пишут (вернее давно уже написали) свои классы с использованием winsock API . Это только моё мнение (хотя и некоторых программеров ещё). В противном случае, давай говорить, что хорошо это - сокеты MFC (это MS), или компоненты BCB++, или Indi.
На скоряк - да. Но только не надо забывать, что ведь и платить надо. Это ж не бесплатные продукты.

vg писал(а):

3. Если хочется писать на С/С++, не забывайте про WinINet

Этим пользуются дети. Или когда программер поставлен в такие условия. Профи пишут (вернее давно уже написали) свои классы с использованием winsock API .

Прикол, т.е. если понадобиться сделать на Win32 сделать HTTP request, то вы это будете на winsock писать?

1) Прикола нет. Разные задачи - разные средства. Если пишется прокси сервер - только на сокетах, вне зависимости какой риквест. Примеров в инете море.

2) Клиента писал бы "на том", на чём бы мне сказали. Сказали б - изучай и пиши на Джава, у нас здесь такая политика. Писал бы на джава. Сказали б на VB - значит на VB. Разница-то какая, если бабки платят. Сказали ешь, значит ешь. Сказали не ешь, значит не ешь.

ПС. Разумеется, для ХТТР-клиента Вы правы, насчёт WinINet. Может leonid-у и посмотреть в ту сторону.

Marmot писал(а):

vg писал(а):

3. Если хочется писать на С/С++, не забывайте про WinINet

Этим пользуются дети. Или когда программер поставлен в такие условия. Профи пишут (вернее давно уже написали) свои классы с использованием winsock API .

Прикол, т.е. если понадобиться сделать на Win32 сделать HTTP request, то вы это будете на winsock писать?

[trn]Kak vse-taki[/trn] Java [trn]mozg otravljaet[/trn] ...

temp писал(а):

Marmot писал(а):

vg писал(а):

3. Если хочется писать на С/С++, не забывайте про WinINet

Этим пользуются дети. Или когда программер поставлен в такие условия. Профи пишут (вернее давно уже написали) свои классы с использованием winsock API .

Прикол, т.е. если понадобиться сделать на Win32 сделать HTTP request, то вы это будете на winsock писать?

[trn]Kak vse-taki[/trn] Java [trn]mozg otravljaet[/trn] ...

Я чегой-то не так сказал? Ляпнул, типа?
Просветите, будьте любезны...

Я чегой-то не так сказал? Ляпнул, типа?
Просветите, будьте любезны...

А я так тоже не прикололся. Java - то причём?

Marmot писал(а):

temp писал(а):

Marmot писал(а):

vg писал(а):

3. Если хочется писать на С/С++, не забывайте про WinINet

Этим пользуются дети. Или когда программер поставлен в такие условия. Профи пишут (вернее давно уже написали) свои классы с использованием winsock API .

Прикол, т.е. если понадобиться сделать на Win32 сделать HTTP request, то вы это будете на winsock писать?

[trn]Kak vse-taki[/trn] Java [trn]mozg otravljaet[/trn] ...

Я чегой-то не так сказал? Ляпнул, типа?
Просветите, будьте любезны...

[trn]nu mozhet ja slegka pereobshchil , odnako osnovnoj point byl v tom, chto dlja nekotoryh zadach vremja, trebujushcheesja na osvoenie i ispol'zovanie gotovyh reshenij, prevyshaet vremja nuzhnoe na reshenie zadachi s nulja. Pri wtom chast' ljudej postojanno programmirujushih na .. hmm .. [/trn]rapid-development[trn] jazykah chashche sklonjajutsja k pervomu podhodu, vkljuchaja sluchai kogda wto sovershenno ne umestno.[/trn] WinInet [trn]i[/trn] HTTP - [trn]tipichnyj tomu primer[/trn].

temp писал(а): [trn]nu mozhet ja slegka pereobshchil , odnako osnovnoj point byl v tom, chto dlja nekotoryh zadach vremja, trebujushcheesja na osvoenie i ispol'zovanie gotovyh reshenij, prevyshaet vremja nuzhnoe na reshenie zadachi s nulja. Pri wtom chast' ljudej postojanno programmirujushih na .. hmm .. [/trn]rapid-development[trn] jazykah chashche sklonjajutsja k pervomu podhodu, vkljuchaja sluchai kogda wto sovershenno ne umestno.[/trn] WinInet [trn]i[/trn] HTTP - [trn]tipichnyj tomu primer[/trn].

Ааа..., понятно, ну если вам нравится ручками проходить через proxy, работать с SSL (HTTPS), разбираться во всех тонкостях HTTP 1.1 тогда, вперёд, winsock вам в руки...
Я всегда исхожу не столько из удобства программирования для конкретного девелопера, сколько из комплекса затрат на всех этапах: разработка, тестирование, поддержка продукта, релиз новой версии и т.д.
Т.е. если надо сделать HTTP request из Win32 (и нету никаких специфических требований), я бы всё-таки настаивал на использовании wininet.
А лучше всего конечно Java + HTTPClient от Apache

ЗЫ обсуждение плавно переходит в религиозную дискуссию

ЗЗЫ В догонку, "часть людей постоянно программируюших на .. хмм .." slow-development языках чаще склоняются к вырезанию гландов автогеном через задний проход

Мои пять копеек.
Думаю, и тот и другой прав.
В принципе подмечено верно, что часто программер упирается от использования нового и удобного, пусть даже гнусного RAPID. И не потому, что это плохо, а потому, что это надо изучать. А времени не хватает.
Помню, как долго я упирался от программирования для Windows 2.0.
Всё делал для DOS. Причём вся графика писана была руками (программировались напрямую порты VGA). Чуство собственного достоинства торжествовало. Идиотизм. Сейчас с грустью смотрю на всё это. Сколько времени и сил было портачено. Всё зря. Всё в корзину. А так, может чему и научился бы, если б ещё тогда изучая программирование для Windows, и уже тогда появляющиеся всякие там RAPID. Так, что Marmot, ежели доведётся - поизучаю Java или VB или C#.