Чтобы добавлять сообщения и комментарии, .

@Macil:
Macil

С ужасом осознал, что соврешенно не умею писать сетевые проги на Х-е. В общем, есть клиент что-то типа недоджсонрпц, который: а) может в произвольный момент послать сообщение серверу; б) в любое произвольное время может получить сообщение от сервера. С тем как увязывать запрос-ответ проблем нет, а вот как это выглядит с точки зрения сокетов и/или ИО-менеджера? Есть ли какой-то идиоматичный пример на Х-е?

@folex:
folex

Жуйк, вот тут github.com есть метод Available_internal. Я чото не могу придумать, как мне достать его исходники.
Собственно, как?

@segfault:
segfault

Нужна программа, которая отправляет по сети, то что я ввожу с клавиатуры и параллельно печатает на экране, то что мне присылают по сети. Аля консоль, только с характерной спецификой
Как ?

@segfault:
segfault

200 строчный udp-чат на сишке

@pc:
pc

REGEDIT4

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters]
"IRPStackSize"=dword:00000012

@k0st1x:
k0st1x

Mains sockets pic.twitter.comvia twitter.com

@L29Ah:
L29Ah

UNIX domain sockets могут one to many без ретранслирующего костыля?

@kb:
kb

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

@kb:
kb

а вы понимаете, как работает, к примеру, gunicorn?

для тех, кто не в курсе, я поясню. у вас есть сервер, который хочет:
1. иметь несколько воркеров, на один из которых и пойдёт обработка запроса, то есть работать не в один процесс, а в несколько (иначе будете испытывать преимущества только одного ядра).
2. с другой стороны, вы не хотите, чтоб воркеры простаивали на socket-запросах (типа запрос в БД или подобное), потому хотите, чтоб воркеры работали с сокетами через какой-нибудь eventlet (на время запроса засыпали и переключались на другой зелёный поток, если надо)

Но проблема в том, что предугадать задержки на сокетах у воркеров невозможно, и узнать их тоже некак. Потому, на сколько я понял, они действительно кормятся тупо все, но делается предположение, что, скажем, 10 запросов на один воркер ну уж точно ему хватит ("одновременно" обрабатывать, в зелёных потоках), а на остальное мы настроим, скажем, nginx, который будет держать их в очереди.

Почему nginx, а не, скажем, наш "главный" процесс? (который за воркерами следит) Вот тут у меня и возникает вопрос: как оно вообще распределяет запросы? Если я правильно понял — оно всем воркерам расшаривает одни и те же сокеты (через /tmp/somefile UNIX-сокет), и те все асинхронно из всех читают, но каким-то образом получается чтение только у одного из воркеров.

В общем, прошу объяснить мне вот этот трюк (если кто знает) с расшариванием сокетов. Спасибо.

@kb:
kb

Вот объясните мне, пожалуйста. Если я делаю с одной стороны send() какой-то строки, а с другой стороны делается recv(), сообщение может дойти не полностью, а в несколько recv()'ов? Или, всё же, можно надеяться, что оно либо дойдет, либо не дойдёт?

И второй вопрос: если я делаю асинхронный recv() (можно через select, можно через libevent/epoll), при этом с большой вероятностью зная, что может быть клиент уже ничего не пошлет, но сокет не закроет. Ничего ведь страшного? Это ведь нормально? (чтоб не городить контрольные суммы переговоров и их длинну и т.п.)

Спасибо.

@mikeb:
mikeb

зафигачил фичу, что когда делается divert-to соединения в локальный сокет, то getsockopt(SO_RTABLE) на accept'нутом сокете вернет номер исходного routing домена. это позволяет держать один ftp-proxy на все routing домены и автоматом разбираться с vrf.

@kb:
kb

Джуйк, рас уж конференция джаббер.сру сломалась, подскажи, пожалуйста. Какоая есть более надежная и простая замена этим сокетам? Мне всего-то надо запускать программу с сервера на компутере за натом по определенному сигналу (то есть надо чтоб клиент "слушал" сервер, и, получив указание, выполнял программку одну). Спасибо, о Джуйк!