Задача:На freebsd машине есть некое подобие шлюза реализованного таким образом
1) "сервер1" который принимает поток (файлы) по TCP от "клиент1".
2) "сервер2" который отдает поток принятый "сервер1" по TCP к "клиент2".Вопрос: каким образом лучше организовать передачу потока от "сервер1" к "сервер2": "Unix socket" или "TCP через localhost" если учесть что доставка пакетов между клиентами должна быть 100% и нагрузка на сервер должна быть как можно меньше (таких передач одновременно будет очень много на очень больших скоростях).
Все пишется на С++ под FreeBSD 8.
Очень надеюсь на компетентный ответ или совет.
Заранее очень благодарен.
>[оверквотинг удален]
>socket" или "TCP через localhost" если учесть что доставка пакетов между
>клиентами должна быть 100% и нагрузка на сервер должна быть как
>можно меньше (таких передач одновременно будет очень много на очень больших
>скоростях).
>
>Все пишется на С++ под FreeBSD 8.
>
>Очень надеюсь на компетентный ответ или совет.
>
>Заранее очень благодарен.общеизвестный факт что через сокет быстрее )) нет накладных расходов TCP
>
>общеизвестный факт что через сокет быстрее )) нет накладных расходов TCPа как надежность?
гарантирует ли Unix Socket доставку "пакетов"?
>гарантирует ли Unix Socket доставку "пакетов"?а гарантирует ли pipe доставку данных?
вопрос из той же серии
>
>>гарантирует ли Unix Socket доставку "пакетов"?
>
>а гарантирует ли pipe доставку данных?
>
>вопрос из той же сериивсмысле?
TCP - гарантирует. UDP - нет.
по Unix Socket - не нашел точного утверждения. в этом и вопрос.
>TCP - гарантирует. UDP - нет.TCP, UDP - это транспортный уровень
unix socket там не причем
>
>>TCP - гарантирует. UDP - нет.
>
>TCP, UDP - это транспортный уровень
>unix socket там не причемпоэтому я и написал слово пакеты как "пакеты". меня интересует надежность доставки у него такая же как у TCP или нет. допускает ли он потери данных по своей спецификации?
>>>TCP - гарантирует. UDP - нет.
>>
>>TCP, UDP - это транспортный уровень
>>unix socket там не причем
>
>поэтому я и написал слово пакеты как "пакеты". меня интересует надежность доставки
>у него такая же как у TCP или нет. допускает ли
>он потери данных по своей спецификации?UDP не гарантирует доставку пакетов не потому, что он их специально про#@$%, а потому что при передаче по сети, какое-либо из промежуточных соединений может быть нарушено (и чем длиннее и сложнее маршрут, тем это вероятнее). TCP в этом случае перепосылает пакет по другому маршруту. То есть, если использовать UDP на двух машинах в одном ethernet-сегменте, к примеру, то тоже ничего никуда не потеряется и порядок следования пакетов нарушен не будет, но эти протоколы работают на другом уровне, независимо от физической конфигурации сети. К UNIX-сокетам, как уже говорили выше, всё это не имеет никакого отношения, потому что оба их конца находятся на одной машине и "потеряться" просто ничего не может. TCP вам стоит использовать только в том случае, если предполагается в будущем разнесение "сервер1" и "сервер2" на разные машины.
>[оверквотинг удален]
>может быть нарушено (и чем длиннее и сложнее маршрут, тем это
>вероятнее). TCP в этом случае перепосылает пакет по другому маршруту. То
>есть, если использовать UDP на двух машинах в одном ethernet-сегменте, к
>примеру, то тоже ничего никуда не потеряется и порядок следования пакетов
>нарушен не будет, но эти протоколы работают на другом уровне, независимо
>от физической конфигурации сети. К UNIX-сокетам, как уже говорили выше, всё
>это не имеет никакого отношения, потому что оба их конца находятся
>на одной машине и "потеряться" просто ничего не может. TCP вам
>стоит использовать только в том случае, если предполагается в будущем разнесение
>"сервер1" и "сервер2" на разные машины.вот за этот совет огромное спасибо. наверно все таки будет Unix Socket так как в ближайшее время разнесение не потребуется.
а почему я спрашивал и за TCP - у него есть два важных преимущества
1) осуществляет повторный запрос данных в случае потери пакета
2) устраняет дублирование пакетовскорость через этот шлюз будет от 350-390 Мбит/с и дополнительно проверять целосность - не ахти. развечто по хеш сумме на спороне принявшего.
>а почему я спрашивал и за TCP - у него есть два
>важных преимущества
>1) осуществляет повторный запрос данных в случае потери пакета
>2) устраняет дублирование пакетовНе читал остальной поток мыслей, но если вы спрашиваете про unix socket, значит работаете локально. Если работаете локально, использовать TCP - идиотизм, и означенные его преимущества таковыми не являются, потому что через сокеты вообще нет никаких пакетов, и вообще невозможна их потеря или дублирование. Плюс гораздо меньшие накладные расходы.
>Не читал остальной поток мыслей, но если вы спрашиваете про unix socket,
>значит работаете локально. Если работаете локально, использовать TCP - идиотизм, и
>означенные его преимущества таковыми не являются, потому что через сокеты вообще
>нет никаких пакетов, и вообще невозможна их потеря или дублирование. Плюс
>гораздо меньшие накладные расходы.tnx
Мда ... вот кому то "повезёт" - от такого прохфессионала программу в продакшен :(И уж если с++ (все реальные кульЦхаккеры на нем пишут, правда?) - то быстрее всего будет SHM, но надёжность доставки у неё как посчитать я не знаю :)
>Мда ... вот кому то "повезёт" - от такого прохфессионала программу в
>продакшен :(
>
>И уж если с++ (все реальные кульЦхаккеры на нем пишут, правда?) -
>то быстрее всего будет SHM, но надёжность доставки у неё как
>посчитать я не знаю :)тут дело не в "кулхацкерах", а в том что я не вижу смысла и полноценной возможности использовать Perl в данной ситуации, так как мне необходимо проверять и делать изменения в заголовке каждого пакета проходящего через эту связку.
тем более вопрос не о языке программирования, а принципе работы Unix сокетов. так что извените? но ваш коментарий совершенно бесполезный.
>И уж если с++ (все реальные кульЦхаккеры на нем пишут, правда?) -
>то быстрее всего будет SHM, но надёжность доставки у неё как
>посчитать я не знаю :)Вы совсем охренели считать нажедность доставки SHM и Unix сокетов? У них "надежность доставки" ровно такая же как "надежность присваивания переменной значения", потому что в обоих случаях это всего лишь запись в память.
>Вы совсем охренели считать нажедность доставки SHM и Unix сокетов?Мужик ну ты чё всё испортил то?! Народ тут стебётя а ты сразу шашкой :\
>Мужик ну ты чё всё испортил то?! Народ тут стебётя а ты
>сразу шашкой :\лучше бы кинули где почитать про принцип реализации Unix сокетов... а не стебетесь :)
>>Мужик ну ты чё всё испортил то?! Народ тут стебётя а ты
>>сразу шашкой :\
>
>лучше бы кинули где почитать про принцип реализации Unix сокетов... а не
>стебетесь :)млять ты не поверишь ....
man socket ....PS на какой планете обучают таких мегокодеров?
>млять ты не поверишь ....
>man socket ....
>
>PS на какой планете обучают таких мегокодеров?если пытаешься кого то учить - расшарь сначала сам...
man unix вообще то....PS и не надо тут бить в грудь - можно просто ничего не писать если не хочешь/не знаешь.
>если пытаешься кого то учить - расшарь сначала сам...
>man unix вообще то....я раз что ты заметил
SEE ALSO в мане - ты очень способный>PS и не надо тут бить в грудь - можно просто ничего
>не писать если не хочешь/не знаешь.расшарь? чего расшарить?
>расшарь? чего расшарить?ваш коментарии совершенно бесполезные...
прочитайте лучше первый пост и скажите если есть что по делу. а не ведете разговор "ни о чем".
>прочитайте лучше первый пост и скажите если есть что по делу. а
>не ведете разговор "ни о чем".что тут еще можно сказать? по моему все уже ясно!
>если пытаешься кого то учить - расшарь сначала сам...расшарь? чаво расшарить?
>man unix вообще то....
я рад что ты заметил
SEE ALSO в мане - ты очень способный!>PS и не надо тут бить в грудь - можно просто ничего
>не писать если не хочешь/не знаешь.1) это не я, а ты выставлдяешь себе "грамотным" так как тема изначально шизофренизм полный, ответы на твои вопросы даст любой поисковик в первой попытки
2) никто не бъет в грудь - просто тыкают носом ))
3) надежность сокетов, пакеты .... жесть ...
я и не говорил что я "гуру".
>я и не говорил что я "гуру".Ну и нефиг "губы дуть", иди читай.
Автору посоветую все книги Ричарда Стивенса, признанного гуру UNIX-программирования и TCP/IP1. У. Ричард Стивенс, Стивен А. Раго
UNIX. Профессиональное программирование
Advanced Programming in the UNIX Environment
Твердый переплет (2007)2. Уильям Стивенс
Unix. Взаимодействие процессов
UNIX Network Programming. Volume 2. Interprocess Communications3. У. Р. Стивенс, Б. Феннер, Э. М. Рудофф
UNIX. Разработка сетевых приложений
UNIX: Network Programming
Твердый переплет (2007)
ну и до кучи4. У. Ричард Стивенс
Протоколы TCP/IP. Практическое руководство
TCP/IP Illustrated, volume 1. The Protocols
Мягкая обложка (2003)
огромное спасибо :)из всех как первых двух не было. походу именно их мне и не хватает...
>На freebsd машине есть некое подобие шлюза реализованного таким образом
>1) "сервер1" который принимает поток (файлы) по TCP от "клиент1".
>2) "сервер2" который отдает поток принятый "сервер1" по TCP к "клиент2".
>
>Вопрос: каким образом лучше организовать передачу потока от "сервер1" к "сервер2": "Unix >socket" или "TCP через localhost" если учесть что доставка пакетов между клиентами должна >быть 100% и нагрузка на сервер должна быть как можно меньше (таких передач одновременно >будет очень много на очень больших скоростях).Так как проги-сервера 2, то стоит подумать о возможности масштабирования. Т.Е. о физическом разделении на 2 компа.
Считаю, что лучше сделать 2 вида - unix socket и tcp. Либу использовать libev - там всего десяток строчек добавиться для поддержки 2-х типов сокетов. И клиентов за 10К можно подключить при правильном написании. Но может быть сложновато, придется повозиться...
>Считаю, что лучше сделать 2 вида - unix socket и tcp. Либу
>использовать libev - там всего десяток строчек добавиться для поддержки 2-х
>типов сокетов. И клиентов за 10К можно подключить при правильном написании.
>Но может быть сложновато, придется повозиться...спасибо, я так и думаю делать, но на первых парах хватит и Unix Socket.
пока курю сокеты в Java так как клиенты будут на ней.за libdev спасибо - посмотрю.
p.s. жесть начнется когда SSL надо будет прикручивать :)