Программирование[11]

У тебя каша в голове Дуит

Ты смешал TCP и мультитрединг

Just.Doit написал 4 минуты назад:

задефайни "отрпавил" тогда

Записал в сокет.

Just.Doit написал 5 минут назад:

что делать если я хочу максимально параллельно слать

Заводить множество конектов.

В TCP нельзя "параллельно слать", тем более делать это максимально.

Vova написал 1 минуту назад:

У тебя каша в голове Дуит

 

Ты смешал TCP и мультитрединг

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

это конеш классика

но над софтскиллами бы поработать

(мне не надо потому что мне покс как как до вас доходит информация, хехе)

GoldRobot написал 4 минуты назад:

В TCP нельзя "параллельно слать", тем более делать это максимально.

в один коннект угу. но я то про создание/использование коннкета на каждую отсулку в параллель

GoldRobot написал 5 минут назад:

Заводить множество конектов.

ну именно

GoldRobot написал 2 минуты назад:

Заводить множество конектов.

В TCP нельзя "параллельно слать", тем более делать это максимально.

Не уверен что это значит "параллельно слать"

Пакеты или сегменты или как там их шлются параллельно всегда Именно поэтому скорость у TCP такая же как у UDP

Просто во время получения эти пакеты или сегменты или как там их записываются в буффер в нужном порядке и сидят в буффере пока все эти хуйни не прилетят

Vova написал Только что:

Не уверен что это значит "параллельно слать"

Пакеты или сегменты или как там их шлются параллельно всегда Именно поэтому скорость у TCP такая же как у UDP

Это TCP их шлет параллельно, но не ты.

Just.Doit написал 5 минут назад:

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

это конеш классика

но над софтскиллами бы поработать

(мне не надо потому что мне покс как как до вас доходит информация, хехе)

Нет это ты на утверждение про TCP высираешь свой бред неуместный про ивент драйвен программинг ни к селу

И мы типо должны в этом бреду еще разбираться? кек

GoldRobot написал 1 минуту назад:

Vova написал 2 минуты назад:

Не уверен что это значит "параллельно слать"

Пакеты или сегменты или как там их шлются параллельно всегда Именно поэтому скорость у TCP такая же как у UDP

Это TCP их шлет параллельно, но не ты.

Ну как клиент ты можешь слать только последовательно Согл

Я только не очень понимаю на кой фиг слать что-то параллельно если скорости это не увеличит

Vova написал 2 минуты назад:

Я только не очень понимаю на кой фиг слать что-то параллельно если скорости это не увеличит

Просто, как я понял, дуит думает что можно сделать одновременно в разных потоках

socket.write(msg1)

socket.write(msg2)

И пытается нас сказать что нет гарантии порядка в таком случае, что на той стороне придет msg1 перед msg2. На самом деле ты вообще ни то ни другое можешь не получить в таком случае. Ты скорее всего получишь кашу msmsg1g2.

Короче три уровня

1) клиентский. Пользовательское приложение может через библиотеку в сокет писать хоть тыщей виртуальных потоков забив хуй на то чтобы задумываться в какой последовательности эти пакеты отправятся.

2) библиотечно/драйверный. Обрабатывает всевозможные варианты, но как абстракция гарантирует, что tcp пакеты из этой абстракции забираются последовательно в соответствии с тем как в неё записали 

3) кабель. Вообще что угодно происходит. Ворона клюнула и 10 секунд слово хуй транслировалось (пишу пост ради этого предложения бтв) 

Все так?

А в чем спор тогда? 

Спор в том что дуит не до конца все эти 3 уровня понимает, потому у него в голове все смешалось. Из-за этого он не может правильно сформировать свой вопрос. В свою очередь, это приводит к тому что он считает нас дураками, а себя гением (вован покусал).

в 1 порт 1 поток, 1 поток строго последователен силами тсп, конец

если ты создал 2 порта, они никак не связаны, офк они могут быть параллельны

Just.Doit написал 43 минуты назад:

что делать если я хочу максимально параллельно слать, а не начинать отправку второго ТОЛЬКО после завершения отправки первого?

я то про этот кейс. а ты про последовательный

очевидно что если слать последовательно то придут последовательно (при наличии подтверждения обработки принимающей стороной, и стартом следующей отправки только после подтверждения о получении второй стороной). я об этом даже не думал потому что это супер тривиальный кейс

судя по тому что ты не понял даже описываемый кейс - каша в голове у тебя...

Очевидная Java головного мозга. Чел совсем не думает про низкий уровень. Нет никакого смысла работать с медленным устройством в несколько потоков. Потому что и сеть, и диск, работают гораздо медленнее оперативной памяти. Аналогично вообще не отдупляешь, что такое асинхронная работа. Это просто постановка задачи в общую очередь. Которую разгребает другой поток. Даже если очередь разгребает пул потоков, то все равно нормальная реализация ввода-вывода предполагает, что следующая задача не начнет выполняться раньше, чем закончилась предыдущая. Иначе начинается та самая Java головного мозга, когда ой сообщение отправленное позже может прийти раньше. Нет, блять, не может, если руки не из жопы.

GoldRobot написал 25 минут назад:

Просто, как я понял, дуит думает что можно сделать одновременно в разных потоках

socket.write(msg1)

socket.write(msg2)

И пытается нас сказать что нет гарантии порядка в таком случае, что на той стороне придет msg1 перед msg2. На самом деле ты вообще ни то ни другое можешь не получить в таком случае. Ты скорее всего получишь кашу msmsg1g2.

Не может такого быть. Сначала сообщение кладется в буфер. Буфер у одного сокета общий. Если сокет выкинет тебе "я отправил 100 байт из 1000 которые ты просил" и ты в цикле начнешь отправлять следующие 900, а в это время другой поток будет делать тоже самое, то да, пизда будет.

PS Хотя что с буферами у сокетов/файлов, если их открыть несколько раз в разных местах и иметь разные дескрипторы, то я хз. Не так много приходилось работать и пытаться выстрелить себе в ногу.

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

Grohuf написал 27 минут назад:

Не может такого быть. Сначала сообщение кладется в буфер. Буфер у одного сокета общий. Если сокет выкинет тебе "я отправил 100 байт из 1000 которые ты просил" и ты в цикле начнешь отправлять следующие 900, а в это время другой поток будет делать тоже самое, то да, пизда будет.

 

PS Хотя что с буферами у сокетов/файлов, если их открыть несколько раз в разных местах и иметь разные дескрипторы, то я хз. Не так много приходилось работать и пытаться выстрелить себе в ногу.

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

Что ты блять несешь?

Запись в сокет с клиентской точки зрения устроена идентично записи в файл

Ознакомься с основами программирования для начала и почитай интерфейсы

Так что msmsg1g2 вполне возможно

Grohuf написал 36 минут назад:

Хотя если несколько сокетов на одном порту попробуют слушать, то вполне возможно коннект получит только один.

Grohuf написал 36 минут назад:

А когда ты коннектишься, то там разный порт будет.

Vova написал 11 минут назад:

Ты тупой?

Vova написал 11 минут назад:

Запись в сокет с клиентской точки зрения устроена идентично записи в файл

Дебил? В файле есть позиция, куда производится запись. Наверное это не спрашивают при собеседовании в гугл?

Grohuf написал 7 минут назад:

Дебил? В файле есть позиция, куда производится запись. Наверное это не спрашивают при собеседовании в гугл?

Дебил есть опция append

https://stackoverflow.com/questions/13378035/socket-and-file-descriptors

Grohuf написал 8 минут назад:

Дебил? В файле есть позиция, куда производится запись. Наверное это не спрашивают при собеседовании в гугл?

Ну файил стримом может быть, named pipe и вот это все, не?

Я всегда думал что сокет таковым и является. Правда хз, а он прям из файловой системы виден? Где-то лежат сокеты?

Vova написал 4 минуты назад:

Grohuf написал 12 минут назад:

Дебил? В файле есть позиция, куда производится запись. Наверное это не спрашивают при собеседовании в гугл?

 

Дебил есть опция append

https://stackoverflow.com/questions/13378035/socket-and-file-descriptors

То, что в линуксе разрешают хуярить в сокет как в файл, не делает их одинаковыми. Иначе не делали бы для сокетов отдельное API.

Grohuf написал 55 минут назад:

PS Хотя что с буферами у сокетов/файлов, если их открыть несколько раз в разных местах и иметь разные дескрипторы, то я хз. Не так много приходилось работать и пытаться выстрелить себе в ногу.

Даже один дескриптор если.

Тот же ofstream открой, да с разных потоках попиши туда. Все будет в порядке, не смотря на то что это вроде как UB, но в файле ты увидишь кашу.

Даже хуйня и с cout

GoldRobot написал 4 минуты назад:

Grohuf написал 14 минут назад:

Дебил? В файле есть позиция, куда производится запись. Наверное это не спрашивают при собеседовании в гугл?

Ну файил стримом может быть, named pipe и вот это все, не?

Я всегда думал что сокет таковым и является. Правда хз, а он прям из файловой системы виден? Где-то лежат сокеты?

Если сокет открыт в режиме UDP, то каким образом можно в него писать как в стрим? Просто в линуксе нахуярили абстракцию и типо это круто.

Grohuf написал 2 минуты назад:

Vova написал 7 минут назад:

Grohuf написал 15 минут назад:

Дебил? В файле есть позиция, куда производится запись. Наверное это не спрашивают при собеседовании в гугл?

 

Дебил есть опция append

https://stackoverflow.com/questions/13378035/socket-and-file-descriptors

То, что в линуксе разрешают хуярить в сокет как в файл, не делает их одинаковыми. Иначе не делали бы для сокетов отдельное API.

Обученный

Ты видишь int?

https://linux.die.net/man/2/read

GoldRobot написал Только что:

Grohuf написал 59 минут назад:

PS Хотя что с буферами у сокетов/файлов, если их открыть несколько раз в разных местах и иметь разные дескрипторы, то я хз. Не так много приходилось работать и пытаться выстрелить себе в ногу.

Даже один дескриптор если.

Тот же ofstream открой, да с разных потоках попиши туда. Все будет в порядке, не смотря на то что это вроде как UB, но в файле ты увидишь кашу.

Даже хуйня и с cout

Смысла смотреть ofsteam я особо не вижу. Надо смотреть системные функции, которые потокобезопасны.

Vova написал 2 минуты назад:

Grohuf написал 6 минут назад:

Vova написал 11 минут назад:

Grohuf написал 19 минут назад:

Дебил? В файле есть позиция, куда производится запись. Наверное это не спрашивают при собеседовании в гугл?

 

Дебил есть опция append

https://stackoverflow.com/questions/13378035/socket-and-file-descriptors

То, что в линуксе разрешают хуярить в сокет как в файл, не делает их одинаковыми. Иначе не делали бы для сокетов отдельное API.

 

Обученный

 

Ты видишь int?

 

https://linux.die.net/man/2/read

Чего ты мне пытаешься втюхать я чего-то не догоняю.