Сетевое взаимнодействие приложений

SSL, например.

И вообще, какие протоколы принято использовать для общения, в пределах wan?

SSH?

openssl

свой протокл с метками последовательности

прежде чем писать нарисуй взаимодействие на бумаге

Пы.Сы. Только чаще всего забивают на эту безопасность: я не раз видел, как форма аутентификации висит себе на http… Жесть!

Смешно, но я совсем про это не подумал.
Спасибо за ответ.

SSH?

Вы сказали просто так, или у вас есть написанные вами приложения, работающие поверх сети, и использующие ssh?

прежде чем писать нарисуй взаимодействие на бумаге

Мой метод восприятия мира, не позволяет мне действовать иначе, чем через визуальное восприятие :)

свой протокл с метками последовательности

Ну, на том же телнете я свелосипидировал секурность - но это не то, чего бы я хотел

Пы.Сы. Только чаще всего забивают на эту безопасность: я не раз видел, как форма аутентификации висит себе на http… Жесть!

Я знаю, мир - страшная штука. Сначала это вызывало смех. Но чем дольше живу - тем печальней встречать подобное.
Нет, увы - я завуалированный консерватор, который любит делать всё без изъянов.

А я долго матюгался, когда узнал, что браузеры не позволяют отправлять с http XHR на https.

Хорошо, что хоть iframe'ы пока не забанили. Правда, судя по тому, что в некоторых некошерных браузерах даже XSS «аппаратно» забанили, процесс написания веб-приложений скоро будет эдаким квестом.

Ладно, хоть вебсокеты пока что не думают убивать…

пока что

Я предвижу, что это ключевая фраза.
Ибо наблюдая за систематичностью смены тенденций - и это может стать реальностью.

Ничего: напишем свой браузер, когда и огнелис скурвится окончательно.

Предвижу реинкарнацию ФИДО…

/usr/bin/client | ssh login@server.addr «/usr/bin/server» ?

Мы с ребятами, на работе, буквально в эту пятницу, обсуждали подобную идею О_о

Ну или два пайпа, если нужен обмен в обе стороны.

Придется, наверное, делать сеть на основе p2p. И свои спутники запускать. И кабели прокладывать…

Лучше уже как-то модифицировать радиосвязь, и работать поверх неё :)

Радиосвязь - хреновая штука: УКВ ограничена прямой видимостью, а ДВ имеют слишком низкую частоту (скорость же будет никакущая). Да и ретрансляторов уйму ставить надо будет.

Да ладно: чего мы убиваемся? Третья мировая спасет мир от информационного коллапса.

То что я ляпнул такую глупость, должно было бы намекнуть, что в радиосвязи я ничего не понимаю :)
Но как идея - я приверженец позиции, о разработке чего-то нового, или тотальной модификации старого - без надобности укладывать свои кабеля и запускать свои спутники. Но было бы так всё просто - это бы уже было. Увы.

Основная линия связи с Америкой до сих пор - оптоволокно, лежащее на дне океана. Радиосвязь - это уж слишком медленно.

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

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

Вы сказали просто так, или у вас есть написанные вами приложения, работающие поверх сети, и использующие ssh?

У меня есть. Как и предлагали выше, запускаем что то через ssh и обмениваемся с ним через стандартные ввод/вывод + какие то протоколы сериализации при необходимости, не забывая при этом сбрасывать буфера. ИМНО самый простой путь позволяющий не влезать в сетевые дебри.

Ну это как вариант, спасибо.
Но как быть, если снова же - канал не стабилен?
ssh сессия просто замерзает, она не восстанавливается, а это может быть критично же

тред не читал. ssl умеет, хотя не уверен на счёт стабильности. теоретически стабильность обеспечивается tcp.

это как... она же восстанавливается когда снова появляется сеть, и лишь когда несколько минут нет коннекта - только тогда уже отваливается

совсем уж так, при настолько низкой стабильности, оно же нормально держит

у меня не раз было такое, что просто при ребуте роутера, к примеру, отваливался на смерть. а это секунд 20, от силы

а, ну при таком сбое извините у ОСьки интерфейс пропадает, сигналы всякие умные о том что связь пропала посылаются и ssh на них разумеется реагирует - делай реконнект

хорошо, если через запуск ssh из командной строки кажется костыльным (а мне он именно таким и кажется) - то есть http://www.libssh2.org

пока что не вижу причины почему бы просто не взять и не использовать эту библиотеку и не ломать голову

вообще как идея, и правда не плохо. мне даже больше чем ssl по нраву.
спасибо

Вы сказали просто так, или у вас есть написанные вами приложения, работающие поверх сети, и использующие ssh?

у меня нет, но встречался. Ssh это ведь протокол, а не шелл, по нему можно что угодно гонять, причём он лучше ssl потому как ИМХО несколько безопаснее, если конечно ключи есть на обоих концах. OpenSSL умеет создавать защищённый канал даже когда клиент впервые видит сервер, оно конечно полезно для сефинга в www, но ИМХО вам не нужно.

А вот свой протокол лучше НЕ писать, если вы конечно не супер-эксперт по безопасности, и таких уже Over9000 написали - сломают, причём на раз. Если конечно целью такой зададутся. А вот SSH/SSL - вряд-ли...

пока что не вижу причины почему бы просто не взять и не использовать эту библиотеку и не ломать голову

+100500. Неужели кто-то подумал, что я предлагаю свою реализацию писать? Это ИМХО глупо.

Я не стану говорить, что сначала пишется все как есть без шифрования, сжатия и т.п., и предложу варианты:

1. TLS/SSL 2. VPN, ssh, etc 3. Пишем свою шифровалку/дешифровалку 4. Использование особенностей сети: vlan, IPsec и т.п.

1, 2 и 4 пункты не требуют ничего кроме готового протокола (в plain text), по которому гоняются нужные данные. 2, 4 даже не требуют вмешательства в код.

Один из самых простых вариантов: пишите обычное приложение для работы с tcp сокетами, а затем используете stunnel (http://www.stunnel.org/?page=docs), приложение, которое пускает ваш траффик через SSL.

Ну ssl же.

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

а вот libssh2... я смотрю что http://packages.ubuntu.com/precise/openssh-client оригинальный openssh клиент базируется поверх libssl непосредственно, так что тут уже надо думать насколько популярная эта библиотека и исправляют ли в ней оперативно уязвимости

openssh вроде более популярная распространенная реализация, кто знает, у нее есть модификация или часть в виде библиотеки?

Но как быть, если снова же - канал не стабилен?

У меня коннект поднимается только при необходимости. Когда клиенту надо получить с сервера новую задачу, он стучится на сервер по ssh и запускает там скриптик, заливает на него сериализованные параметры через stdin, скритптик копается в репозитории и сливает результат через stdout, коннект рвется до след. сессии.

SSL наверное правильнее, но такой вариант гораздо проще и быстрее реализуется (не надо какие то бибилиотеки искать) + типовые настройки аутентификации.

Это все верно, но многие программисты любят котролировать ситуацию. Твое решение является хорошим, если надо все быстро сделать но немного паршиво, когда время ценнее качества. Но если пишешь серьезный код, лучше полностью контроллировать процесс соединения и дальнейшей сетевой коммуникации. Да и сторонний программный комнонент должен вести себя достаточно предсказуемым образом. Программы ssh по-просту может не оказаться на машине, или окажется, но какая-то не такая.

Э... если ssh нету на машине, то как я на нее вошел и поднял сервер? O_O ;-)

Ну это я образно. :-)

имхо - у вас в голове каша какая то

поверх телнета - это одно и тоже что поверх tcp - разници почти никакой
и да - ваще приложение долно уметь обрабатывать потерю коннекта с другой стороны - переконекчиваться - таймауты и так далее
это данная реальность - и всякое в ней бывает - от выключенного компа - до глючащей сетевой

а приложение работающее поверх ssh - это rsync - умеет вполне работать поверь него

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

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

так что тут уже надо думать насколько популярная эта библиотека и исправляют ли в ней оперативно уязвимости

не знаю. у меня в дистре есть http://www.libssh.org/

но на http://www.libssh2.org/ релиз более новый... The latest release: libssh2 1.4.2 from May 18th 2012 Однако, ИМХО в большинство дистров придётся ставить дополнительно

а приложение работающее поверх ssh - это rsync - умеет вполне работать поверь него

таких приложений достаточно много разных.

Я и правда зациклился на постоянной сессии. Замечательное замечание.
Спасибо.