|
|
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
Народ! Кто-нибудь знает, есть ли в природе способ соединить два сокета без помощи третьего (т.е. без listen и accept)? То есть примерно что-то следующее: ---один поток: ... bind(socket1, ....) select(.... recv(socket1, ...) ... ---другой поток connect(socket2, ...) //коннектимся по заранее известному адресу send(socket2, ...) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2006, 15:31 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
Вас интересуют средства передачи данных между потоками? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2006, 15:42 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
похожее есть с UDP сокетом :-) Есть такая штука "Присоединенный UDP сокет" а зачем такое нужно если не секрет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2006, 15:43 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
--null--похожее есть с UDP сокетом :-) Есть такая штука "Присоединенный UDP сокет" Вроде, это только системная установка адресата по умолчанию для сокета, а не установка соединения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2006, 15:50 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
да, естественно. Ибо какое может быть соединение по UDP. Но абстрактно он называется "присоединенным" - например, через него можно обмениваться датаграммами только с присоединенным оппонентом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2006, 16:10 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
Нет, не между потоками. Про потоки - это я для примера попроще... Естественно, я про передачу данных между разными хостами. Нужно - "для экономии на спичках". Пишу что-то типа спайдера для мобильного устройства. Ресурсов - кот наплакал, предел для стека потока - 64 кб. А когда с десяток потоков крутится в памяти, то загрузка процессора 100%. Вот и пытаюсь экономить где можно. Жалко, профайлера нету никакого... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2006, 16:19 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
Makar4ikНужно - "для экономии на спичках". Мысля: а можно закрыть базовый сокет, после получения соединения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2006, 16:32 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
Makar4ikА когда с десяток потоков крутится в памяти, то загрузка процессора 100%. Проверять список сокетов select-ом из ОДНОГО потока accept можно ловить тем-же select-ом ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2006, 16:54 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
--null--да, естественно. Ибо какое может быть соединение по UDP. Но абстрактно он называется "присоединенным" - например, через него можно обмениваться датаграммами только с присоединенным оппонентом. Не обязательно. Это только для возможности пользования send()/write(). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2006, 17:00 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) Makar4ikА когда с десяток потоков крутится в памяти, то загрузка процессора 100%. Проверять список сокетов select-ом из ОДНОГО потока accept можно ловить тем-же select-ом Можно убить нескольких зайцев сразу. Делать через обработку сигнала SIGIO, если пишется под Unix. Не нужно лишний раз дергать select и количество нитей можно уменьшить. Пока ждем SIGIO по одному сокету, нить обрабатывает следующий сокет. В иделале можно уменьшить количество нитей до одной на 1 процессор. При этом спящие нити не будут занимать стэк. Если делать нечего можно заснуть, а приход сигнала SIGIO разбудит процесс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2006, 17:37 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
AkhМысля: а можно закрыть базовый сокет, после получения соединения?Базовый, в смысле серверный? Который Listen? Ну, в принципе можно, конечно, но через 150 мсек его опять создавать придется... Gluk (Kazan)Проверять список сокетов select-ом из ОДНОГО потока accept можно ловить тем-же select-омУ каждого потока порты, по которым сеть слушается - разные. :( Да и толку от создания еще одного лишнего потока... И так протолкнуться негде. :) onstat-Делать через обработку сигнала SIGIO, если пишется под Unix.К сожалению, пишу под Win... В общем, понятно, что под Win32 ловить нечего. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2006, 18:51 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
Makar4ik Gluk (Kazan)Проверять список сокетов select-ом из ОДНОГО потока accept можно ловить тем-же select-омУ каждого потока порты, по которым сеть слушается - разные. :( Да и толку от создания еще одного лишнего потока... И так протолкнуться негде. :) Select -у не важно какие порты, он смотрит на готовность файловых дескрипторов на возможность проведения операции ВВ. Если выпал Listen socket смотите на предмет нового соединения. Если другой смотрите на проведение операции ВВ, или закрытия. ИХМО Select нужно крутить в одной нити для всех дескрипторов, а другим "говорить" что для них что то есть на обработку. Makar4ik onstat-Делать через обработку сигнала SIGIO, если пишется под Unix.К сожалению, пишу под Win... В общем, понятно, что под Win32 ловить нечего. :) Думаю в виндах, что то похожее тоже есть. Нужно смотреть WINAPI глубже, но я в нем не спец. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2006, 19:18 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
onstat-Select нужно крутить в одной нити для всех дескрипторов, а другим "говорить" что для них что то есть на обработку. Для такой схемы мне нужен будет лишний поток, и пачка аспирина, чтобы синхронизировать то, что без лишнего потока синхронизировать было не нужно... Дело не в том, что мне мешает блокировка при ожидании входящего соединения в потоке. Она-таки как раз помогает. Ибо на один поток - один приходящий сокет. Просто я хотел обойтись всего одним сокетом в потоке, но видно не судьба. А лишняя нить для всех дескрипторов - это: 1. синхронизировать передачу в эту нить нового дескриптора. (дополнительный объект синхронизации для "лишней" нити) 2. как-то остановить свою нить, дожидаясь сообщения от "лишней". (дополнительный объект синхронизации (event) для каждой из рабочих нитей). 3. синхронизировать все последующие манипуляции с дескриптором. результат: все равно по 2 сокета на поток, по дополнительному HANDLE для каждого объекта Event на поток, и плюс еще один поток, который бог знает что делает. И куча лишнего геморроя с синхронизацией, и ожиданием передачи управления между потоками. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2006, 21:54 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
Makar4ik onstat-Select нужно крутить в одной нити для всех дескрипторов, а другим "говорить" что для них что то есть на обработку. Для такой схемы мне нужен будет лишний поток,Зачем??? Ты уверен что тебе на микро-ресурсах действительно нужна параллельная обработка приходящих данных? Можно ж вообще одним-единственным потоком обойтись. select() ждет пока в любом из readfds что-нибудь появится и как появилось запускает для всех сокетов с данными процедуру приема и разбора пришедших данных. Потом возвращаемся в главный цикл и снова select(). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2006, 23:25 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
White OwlЗачем??? Ты уверен что тебе на микро-ресурсах действительно нужна параллельная обработка приходящих данных? Не уверен. Но пока проект сырой, и проще отлаживать каждый экземпляр в своем потоке. А так - действительно, можно создавать один поток на 64 сокета... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 00:23 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
Makar4ikНо пока проект сырой, и проще отлаживать каждый экземпляр в своем потоке.Ну отлаживать то как раз проще когда только один поток :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 00:53 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
Makar4ikДа и толку от создания еще одного лишнего потока... И так протолкнуться негде. :) Ты не понял, не ЕЩЕ ОДИН, а ЕДИНСТВЕННЫЙ поток, который обслуживает ВСЕ сокеты/порты (подставь нужное) которые необходимо. Подробности в MSDN ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 08:25 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
Makar4ik White OwlЗачем??? Ты уверен что тебе на микро-ресурсах действительно нужна параллельная обработка приходящих данных? Не уверен. Но пока проект сырой, и проще отлаживать каждый экземпляр в своем потоке. А так - действительно, можно создавать один поток на 64 сокета... Можно создать класс с потоком и отдавать ему каллбаки приписанные к идентификатору сокета. Тогда и отлаживаться будет легко. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 09:45 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) Makar4ikДа и толку от создания еще одного лишнего потока... И так протолкнуться негде. :) Ты не понял, не ЕЩЕ ОДИН, а ЕДИНСТВЕННЫЙ поток, который обслуживает ВСЕ сокеты/порты (подставь нужное) которые необходимо. Подробности в MSDN Тут есть один маленький момент. Если нить(поток) обслуживает клиентские сокеты, то на connect, он будет спать, пока другая сторона не приймет соединение. Если эта задержка не напрягает то можно и в один. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 10:18 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
onstat-Тут есть один маленький момент. Если нить(поток) обслуживает клиентские сокеты, то на connect, он будет спать, пока другая сторона не приймет соединение. Если эта задержка не напрягает то можно и в один. мы вроде об сервере ? какие нафих connect-ы ??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 10:20 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
onstat- Gluk (Kazan) Makar4ikДа и толку от создания еще одного лишнего потока... И так протолкнуться негде. :) Ты не понял, не ЕЩЕ ОДИН, а ЕДИНСТВЕННЫЙ поток, который обслуживает ВСЕ сокеты/порты (подставь нужное) которые необходимо. Подробности в MSDN Тут есть один маленький момент. Если нить(поток) обслуживает клиентские сокеты, то на connect, он будет спать, пока другая сторона не приймет соединение. Если эта задержка не напрягает то можно и в один. Блокирующий сокет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 10:25 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
Makar4ik onstat-Делать через обработку сигнала SIGIO, если пишется под Unix.К сожалению, пишу под Win... В общем, понятно, что под Win32 ловить нечего. :) В винде наверное можно использовать WSAAsyncSelect ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 10:42 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) onstat-Тут есть один маленький момент. Если нить(поток) обслуживает клиентские сокеты, то на connect, он будет спать, пока другая сторона не приймет соединение. Если эта задержка не напрягает то можно и в один. мы вроде об сервере ? какие нафих connect-ы ??? Ну мало ли, мое дело предупредить о том, что это нужно учитывать. Сервер может превратьться в клиента по любым причинам, в болшенстве случаев не зависящим от разработчика, и по опыту очень даже быстро. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 10:57 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
AkhБлокирующий сокет. ичо, поймал уведомление в неблокирующем select-е и читай его блокирующими вызовами наздаровье ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 11:34 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
onstat-Сервер может превратьться в клиента по любым причинам, в болшенстве случаев не зависящим от разработчика, и по опыту очень даже быстро. гнать фшею такого разработчика. Можно на время connect-а сделать сокет неблокирующим, потом восстановить флажок и ждать соединения на select-е. Этот случай также описан в популярной литературе :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 11:37 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) AkhБлокирующий сокет.ичо, поймал уведомление в неблокирующем select-е и читай его блокирующими вызовами наздаровье Я и говорю, что вышеуказанное верно для блокирующего сокета. Речь шла про connect. Не блокирующий сокет вернет errno, что пока сервер не готов. Кстати, если реализовывать в одном потоке с каллбаками по сокетам, то, считаю, что блокировать его потом не стоит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 11:44 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan) onstat-Сервер может превратьться в клиента по любым причинам, в болшенстве случаев не зависящим от разработчика, и по опыту очень даже быстро. гнать фшею такого разработчика. Можно на время connect-а сделать сокет неблокирующим, потом восстановить флажок и ждать соединения на select-е. Этот случай также описан в популярной литературе :) Согласен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 11:45 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
onstat-...Сервер может превратьться в клиента по любым причинам, в болшенстве случаев не зависящим от разработчика, и по опыту очень даже быстро. немного лирики...тьху определений... Сервер - тот кто предоставляет услуги в сети... Клиент - тот кто использует эти услуги. всё, другого нема..хотите этого Вы или нет... Посему любая станция или группа станций может выступать как сервер(а) так и клиенты(ом). Но (!) тут есть маленьчкий нюанс (точнее их гораздо больше, но опустим) - сервер должен предвидеть все те ситуации в которые его может загнать клиент(ы)... Посему не совсем правильно не прокачав эти аспекты делать из клиента сервер (например).. сервер в клиента - это наверное просче, тут затрагиваются в основном проблемы секьюритей и скорострельности.... с уважением (круглый) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 13:30 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
White OwlНу отлаживать то как раз проще когда только один поток :)Приложение все равно многопоточное получается, пользовательский интерфейс все равно в своем потоке. Так что я отлаживаюсь пока как 1+1 поток. 1 интерфейс, 1 задача. onstat-Если эта задержка не напрягает то можно и в один.Напрягает. Очень. Gluk (Kazan)мы вроде об сервере ? какие нафих connect-ы ???Разные. И connect-ы, и accept-ы... Например, тот же SMTP, или FTP сервер обязаны уметь связываться сами. AkhКстати, если реализовывать в одном потоке с каллбаками по сокетам, то, считаю, что блокировать его потом не стоит.А неблокирующие сокеты будут кушать не меньше ресурсов, чем потоки. Если, конечно, потокам не выдавать по мегабайту стека. Gluk (Kazan)гнать фшею такого разработчика. Можно на время connect-а сделать сокет неблокирующим, потом восстановить флажок и ждать соединения на select-е. Этот случай также описан в популярной литературе :)А еще в популярной литературе инопланетян описывают... О! Давайте все хором выгоним "фшею" всех разработчиков SQL, FTP, SMTP, POP3 и проч, и проч... kolobok0Посему любая станция или группа станций может выступать как сервер(а) так и клиенты(ом). А также и отдельно взятая программа. kolobok0сервер в клиента - это наверное просче, тут затрагиваются в основном проблемы секьюритей и скорострельности.... Сервер и клиент - разные вещи. Сервер к примеру должен быть устойчивым и надежным. Ну, по возможности еще и быстрым. Но он не обязан быть таким же умным как клиент. Я не имею сейчас в виду что-то типа SQL сервера... Возьмем, к примеру тот же самый FTP сервер. Ну отправил клиент ему запрос с лишним пробелом на конце. Сервер не обязан при этом его отработать. Вернет ошибку, и делов-то... А клиент обязан разбирать его ответы, парсить текстовые строки, и т.д. и т.п. В случае FTP, или скажем, POP3 протоколов серверы выглядят куда более простыми, нежели клиенты. Все дальнейшее усложнение сервера - это повышение надежности, скорости и управляемости. Просто путь от запорожца к мерседесу. Но колес - все равно столько же, и водитель-клиент этого сервера-мерседеса все равно должен лучше знать, куда рулить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 14:20 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
Makar4ik Gluk (Kazan) Этот случай также описан в популярной литературе :)А еще в популярной литературе инопланетян описывают... О! Давайте все хором выгоним "фшею" всех разработчиков SQL, FTP, SMTP, POP3 и проч, и проч... Макарчик, не слишком ли ты многословен, для человека задающего вопрос ? Не нравится запах - не нюхай (с) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 15:01 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)Макарчик, не слишком ли ты многословен, для человека задающего вопрос ?Ок. Отлично. Ты вопрос-то читал? Перечитай... И свои ответы на него тоже... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 15:07 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
Makar4ik Gluk (Kazan)Макарчик, не слишком ли ты многословен, для человека задающего вопрос ?Ок. Отлично. Ты вопрос-то читал? Перечитай... И свои ответы на него тоже... спасибо, не интересно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 15:35 |
|
||
|
Еще раз про сокеты...
|
|||
|---|---|---|---|
|
#18+
Makar4ik....Сервер и клиент - разные вещи.... истина...одобрям... Makar4ik...Сервер к примеру должен быть устойчивым и надежным. Ну, по возможности еще и быстрым. Но он не обязан быть таким же умным как клиент.... простите Вы противоречите определению - см. выше.. в топку... Или по другому, я наверное открою серкет, но кс решения нуна не только в плоскости умный-быстрый смотреть...Иначе Вам потребуется удача Makar4ik...Я не имею сейчас в виду что-то типа SQL сервера...... на самом деле пофигу что брать... у сиквол сервака кто есть клиент ? прально - его драйвер... весь ум которого заключается в сравнении типов, имён и преобразование к типам того языка под которым он лежит... Makar4ik...Возьмем, к примеру тот же самый FTP сервер.Ну отправил клиент ему запрос с лишним пробелом на конце.Сервер не обязан при этом его отработать. Вернет ошибку, и делов-то...А клиент обязан разбирать его ответы, парсить текстовые строки, и т.д. и т.п.В случае FTP, или скажем, POP3 протоколов серверы выглядят куда более простыми, нежели клиенты....... возьмём.. эххх...я наверное открою большой секрет - но что и кто должен делать те или иные действия определяемые задачей - увы и ах ни каким рэксом не связаны со стороной их обработки.. Не конечно же связаны, но(!) и это очень важно(!!!) НЕТ ШАБЛОННЫХ РЕШЕНИЙ(!!!) вдумайтесь... и прочитайте ышо раз то, что Вы написали постом выше... Поясню... Например у нас один клиент и один сервер (почему бы и нет?) ... Задачи сервака тупо отрабатывать как мона скорее рядом с хранилищем данных (ну задача такая к примеру) - либо на не стандартном железе (пущай будет at89c51rc - это такой МК)...Работу связанную с проверкой формата мы можем водрузить на клиента ? а почему бы и нет ? Кто запретил ? И продолжаем экспиримёнт.. увеличиваем кол-во клиентов...Опс...тут уже всем становиться понятно, что сервак без проверки формата запроса - мягко говоря не жизненное решение...Значит функционал поехал на сервак... надеюсь кривой пример пояснил мою предыдущую мыслю... Makar4ik..Все дальнейшее усложнение сервера - это повышение надежности, скорости и управляемости. Просто путь от запорожца к мерседесу. Но колес - все равно столько же, и водитель-клиент этого сервера-мерседеса все равно должен лучше знать, куда рулить... ну это заблуждение... например берём клиентов со стандартизированным шлюзом(интерфейсом) ну какой нить IE броузер к вэб сервакам..И шо мы видим ? А ничего.. Плевал(и правильно делал в рамках поставленной задачи) клиент на управляемость сервера !!!! с уважением (круглый) ЗЫ Понимаете ли в чём дело мил человек... КС системы тем и хороши, что догм нет...И это НЕТ идёт от определения...см. выше... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.10.2006, 15:39 |
|
||
|
|

start [/forum/topic.php?all=1&fid=57&tid=2030323]: |
0ms |
get settings: |
4ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
408ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
75ms |
get tp. blocked users: |
1ms |
| others: | 202ms |
| total: | 729ms |

| 0 / 0 |
