App=channel<->TCP<->chanel=App есть .... думаю пора бы UDP написать

с процессом можно общаться через stdin-stdout, а можно через unix socket

можно и по tcp, но не нужно

с процессом можно общаться через stdin-stdout, а можно через unix socket

ну ... если один родитель-один дочерний

а если один родитель и много дочерних?

не вижу проблем

не вижу проблем

хотя да

проблем нет ....

мой поинт в том, что для drop priveleges в go нет ровно ничего работающего

а если не на одной машине

тогда запуска родителем дочернего не будет ...

эхххх ...

а если не на одной машине

родина дала нам inetd

с процессом можно общаться через stdin-stdout, а можно через unix socket

named pipe

named pipe

он в одну сторону, так что парой. сокет удобнее

родина дала нам inetd

родина нам и ftpd даже дала

как это смысле в одну? в обе же, точно говорю

^ @onokonem

ээ, в виндвз по крайней мере)

как это смысле в одну? в обе же, точно говорю

пайп, даже именованный, односторонний

ээ, в виндвз по крайней мере)

а. это совсем другая сущность, хоть и имеет тоже название. я так помню, они вообще по UNP доступны, то есть через сеть работают

да, работают, лично делал

пайп, даже именованный, односторонний

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

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

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

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

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

И, сюрприз, в Go все для сокетов есть. :)

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

я с этого начал

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

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

ну да. Но суть в том, что пайпы - полудуплескные, короче

рантайм Go не сможет вернуть конроль над дочерним процессом

а зачем огород-то городить? нормальный протокол FTP не?

FTP - это сааавсем не нормальный протокол. не надо про него вспоминать в 17 году 21 века

я с этого начал

я прочитал "можно порОй")

хм, а я думал, что как раз не надо про него забывать... :)

ээ, в виндвз по крайней мере)

И в солярке. И в других позикс системах

И, сюрприз, в Go все для сокетов есть. :)

net.Listen ?

FTP - это сааавсем не нормальный протокол. не надо про него вспоминать в 17 году 21 века

Да хер с ним с ftp, я файловый манагер хочу и консольку

Да хер с ним с ftp, я файловый манагер хочу и консольку

Есть же механизмы запуска софта

https://golang.org/pkg/os/exec/

Да хер с ним с ftp, я файловый манагер хочу и консольку

да у меня тоже проблемка файловая имеется ... ftp как стандартное приложение не справится

Да хер с ним с ftp, я файловый манагер хочу и консольку

ну тогда https://golang.org/pkg/os/exec/

net.Listen ?

https://gist.github.com/kenshinx/5796276

https://gist.github.com/kenshinx/5796276

понятненько) ну эт мы умеем

есть 2 GO приложения ... оба http-сервера , мне нужно при появлении в относительных путях xxx "/xxx/nnn/aa.jpg" брать картинку из другого и поддержать сохранение так же. Рад бы использовать готовое ... но в роутер готовое не вставить! Хотя ... может лучше "выровнять" паблик(статические файлы) к стилю ОДИН-ДЛЯ МНОГИХ

понятненько) ну эт мы умеем

А! или даже так: https://gist.github.com/hakobe/6f70d69b8c5243117787fd488ae7fbf2 Там не TCP-сокет, а UNIX.

unix domain sockets, по идее, работают даже быстрей, чем IP - у ядра с ними бухгалтерии меньше, чтобы соединение поддерживать.

А! или даже так: https://gist.github.com/hakobe/6f70d69b8c5243117787fd488ae7fbf2 Там не TCP-сокет, а UNIX.

вот кстати.. тупой вопрос. как конец принятой посылки различать (в общем случае) в таких системах?

End Of File - конец соединения. Перевод строки - стандартный разделитель

while not EOF

unix domain sockets, по идее, работают даже быстрей, чем IP - у ядра с ними бухгалтерии меньше, чтобы соединение поддерживать.

они софтверные ... им незачем ожидать ответов оборудования!

они софтверные ... им незачем ожидать ответов оборудования!

им и всю эту IP-шную бухгалтерию вести не надо

по TCP/IP-то можно и локально между процессами общаться, безо всякого оборудования

не, EOF - это когда клиент или сервер порвал коннекцию. а надо чтобы было приём-ответ

прием-ответ - по переводу строки

по TCP/IP-то можно и локально между процессами общаться, безо всякого оборудования

да на локалхосте ... но заглушкой будет TCP стек , а это тяжелая весчь

ну тогда https://golang.org/pkg/os/exec/

Эм...

прием-ответ - по переводу строки

а какой у неё конец? типа \0 или \r\n ?

как у тебя клиент с сервером договорятся. в UNIX обычно просто \n

https://habrahabr.ru/company/pushall/blog/280218/

https://www.tutorialspoint.com/unix_sockets/

https://troydhanson.github.io/network/Unix_domain_sockets.html

как у тебя клиент с сервером договорятся. в UNIX обычно просто \n

ну я тут сам с собой договариваюсь, пока не очень получается. \n не алё - вдруг я буду жсон слать.

ну я тут сам с собой договариваюсь, пока не очень получается. \n не алё - вдруг я буду жсон слать.

дело вкуса ? каждый растит своего ДЕЛИМИТЕРА

ну я тут сам с собой договариваюсь, пока не очень получается. \n не алё - вдруг я буду жсон слать.

А вдруг еще и картинки будешь слать? Юзай уже тогда сразу протобуф какой-нибудь

дело вкуса ? каждый растит своего ДЕЛИМИТЕРА

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

если работает - нормльно! :)

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

ну нормой в 90-е считалось [длина][данные]

дада) у меня так и есть + crc16

ERROR: S client not available

между локальными процессами?

ну нормой в 90-е считалось [длина][данные]

ну, так в Паскакале аррай так и хранился: [0]-длина[1..size]-элементы

а чего тогда не считать SHA512? Это было бы надежней :)

да, чтобы например в гуй чего нибудь передать или получить из него

^ @aadz69

на радиоканалах [длина][Соломона][данные]

Обалдеть! Чем только народ не страдает по выходным :)

Обалдеть! Чем только народ не страдает по выходным :)

на то это и выходные!?

ну, так в Паскакале аррай так и хранился: [0]-длина[1..size]-элементы

в Forth это было стандартом!

а чего тогда не считать SHA512? Это было бы надежней :)

коллега, если вы подумаете хотя бы 5 минут, вы поймете, что crc32 достаточно для обеспечения надежности передачи

в Forth это было стандартом!

+ )))

коллега, если вы подумаете хотя бы 5 минут, вы поймете, что crc32 достаточно для обеспечения надежности передачи

согласен, но с sha512 все равно ни в какое сравнение CRC не идет :)

согласен, но с sha512 все равно ни в какое сравнение CRC не идет :)

как слон для шашлыка ?

но зато выглядит как солидно? посылаешь строку "123" и ней контрольный код, чтобы все выглядело по-взрослому!

но зато выглядит как солидно? посылаешь строку "123" и ней контрольный код, чтобы все выглядело по-взрослому!

а для кого "выглядело" ? Для хакера? Он оценит .... главное AES убрать

нет, для себя! Это же известно, что между локальными процессами UNIX сокет постоянно данные теряет, прямо беда с этими сокетами... :)

AES - не надо. Простенько, посчитал дайджест и уверен, что строка "123" дошла в целостности :)

нет, для себя! Это же известно, что между локальными процессами UNIX сокет постоянно данные теряет, прямо беда с этими сокетами... :)

стоп ... что значит теряет ....? В unix сокетах нет SEQ и ACQ? Ближайший аналог не ТСP?

и главное солидно. там в sha512 дайжест будет 128 байт! Разве не круто?

А! Или нет. 64 байта, но в строковом представлении - 128

стоп ... что значит теряет ....? В unix сокетах нет SEQ и ACQ? Ближайший аналог не ТСP?

это шуточка была

это шуточка была

шутники блин

ну, выходные же... :)

да, чтобы например в гуй чего нибудь передать или получить из него

на самом деле забей. Не нужна тебе контрольная сумма между локальными процессами ни через UNIX сокет, ни через как

на самом деле забей. Не нужна тебе контрольная сумма между локальными процессами ни через UNIX сокет, ни через как

у радиолюбителей .... до сих пор все по взрослому ? , живут в 20-м веке

через сеть нужна, кстати

и точно нужна при шифровании - aes же "расшифровывает" все, что ни дай

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

А mitm?

ну, тогда только шифровать

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

так ему и надо ... в то время когда UDP уже пьет какао не задумываясь о результате как Почта РФ

почта РФ уже допилась какао. Даже страшно с ней и дело-то иметь