https://github.com/firstrow/tcp_server

какие?!

ну как ты включишь jumbo где-нибудь в докере?

ну как ты включишь jumbo где-нибудь в докере?

на хосте включу

на хосте включу

а потом на другом хосте..

может tcp просто бахнуть?

ты бы сформулировал задачу, а?

а потом окажетс что у людей оверлейная сеть

а потом на другом хосте..

на хосте, на хосте и на свитче, да

на каком-нибудь vxxlan

на хосте, на хосте и на свитче, да

это адский геморрой. и фактически нереально, если инфраструктура не своя

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

это адский геморрой. и фактически нереально, если инфраструктура не своя

не адский

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

что именно надо гарантировать?

что отправленный пакет данных доедет до адресата

а не потеряется

TCP, как мы знаем, гарантирует доставку в буфер OS, а не приложению

что отправленный пакет данных доедет до адресата

вариантов 2: 1) udp + подтверждение доставки 2) tcp + подтверждение доставки

https://dchua.com/2017/06/23/sending-your-structs-across-the-wire-(tcp-connection)/

а чем такой сырой вариант не соотвествует?

в случае с udp правда еще надо реассемблинг делать

то есть - реализовывать tcp :)

то есть - реализовывать tcp :)

ну, в tcp сильно-сильно больше.

а чем такой сырой вариант не соотвествует?

подтверждения доставки нет

а чем такой сырой вариант не соотвествует?

мы пока не знаем, чему именно оно (не) соответствует

подтверждения доставки нет

ну там же tcp, он почти всегда доедет

ну там же tcp, он почти всегда доедет

доедет куда?

udp тоже почти всегда доедет

udp тоже почти всегда доедет

кусками )

доедет куда?

до "приёмника"

а, и еще не в том порядке может доехать

udp это траханье с доставкой ?

Хе-хе, это ты еще SIP не видел! Вот где настоящее траханье которое невозможно охладить

до "приёмника"

в socket buffer приемника. не более. дальше нет гарантий

кусками )

мой опыт говорит, что в локалке потерь практически нет, а в интернете и tcp продалбывается. часами можно писать в сокет, который на той стороне отвалился давно. особенно на мобильном инете

мой опыт говорит, что в локалке потерь практически нет, а в интернете и tcp продалбывается. часами можно писать в сокет, который на той стороне отвалился давно. особенно на мобильном инете

у меня иной опыт. udp продалбывается в локалке довольно легко, как только у свитча кончаются буфера. а чтобы они не кончались, надо ставить не говно. в случае с tcp в интернетах надо включать so_keepalive и настраивать его.

с буферами у свитча - на этом месте у tcp начнутся ретрансмиты, которые тоже приведут к потерям в конце концов

может через вебсокет прокинуть и все? хммм

so_keepalive не помогает

с буферами у свитча - на этом месте у tcp начнутся ретрансмиты, которые тоже приведут к потерям в конце концов

потери - нет. ретрансмиты - да.

может через вебсокет прокинуть и все? хммм

как только ты задачу сформулируешь внятно - ответ станет очевиден

so_keepalive не помогает

это еще почему?

ну - такова реальность

я же сформулировал?

нет

ты не сформулировал, гарантий чего ты хочешь

потери - нет. ретрансмиты - да.

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

type Client interface { Send(s *MyStruct) } type Server interface { Receive() chan *MyStruct }

ну - такова реальность

да ладно? я ж говорю: мало просто включить, надо еще и настроить, а не использовать дефолтные значения

и я не хочу знать что внутри ?

да ладно? я ж говорю: мало просто включить, надо еще и настроить, а не использовать дефолтные значения

я проводил эксперименты.

и я не хочу знать что внутри ?

тут нет ничего про гарантии

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

всмысле? свитч просто дропнет фрейм. дальше этот дроп обработает tcp.

тут нет ничего про гарантии

это "спрятанная реализация"

я проводил эксперименты.

ээээ... а как тестил? потому что у меня _внезапно_ все работает.

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

с моей стороны вылетело, как там транспортный протокол думает мне похрену

всмысле? свитч просто дропнет фрейм. дальше этот дроп обработает tcp.

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

главное что бы до сервера на другом конце долетело

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

ну так в tcp есть flow control. ты не сможешь писать в сокет )

главное что бы до сервера на другом конце долетело

сформулируй это человеческим языком. пока все, что ты говоришь, переводится на русский как "гарантии доставки не нужны"

what? O_o

ну так в tcp есть flow control. ты не сможешь писать в сокет )

и что станет с теми данными, которые ты не смог записать в сокет?

сформулируй это человеческим языком. пока все, что ты говоришь, переводится на русский как "гарантии доставки не нужны"

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

what? O_o

ты не хочешь знать, долетело ли оно. значит, тебе не важно, долетело ли

пусть транспорт проверят доставку

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

и что станет с теми данными, которые ты не смог записать в сокет?

это приложенька должна решать.

а что она может нарешать, кроме как дропнуть их?

ERROR: S client not available

type Client interface { Send(s *MyStruct) error }

а что она может нарешать, кроме как дропнуть их?

во-первых, мы словим EAGAIN. во-вторых, когда в SO_SNDBUF будет место, мы сможем туда что-то записать

окуда оно там возьмется?!

и что мы делаем с данными, которые генерятся, пока у нас eagain?

окуда оно там возьмется?!

ну мы все-таки отправляем что-то )

и что мы делаем с данными, которые генерятся, пока у нас eagain?

копить в памяти/на диске. вариантов не много

но это лучше, чем просто запульнуть в сеть без каких-то гарантий

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

но это лучше, чем просто запульнуть в сеть без каких-то гарантий

для чего-то лучше, для чего-то хуже

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

ну так тут ничего не спасёт.

Так если типа гарантии нужны может nats и иже с ними?

ну так тут ничего не спасёт.

именно а если мы отправляем меньше, чем можем передать - и udp ок (в локалке). ну - для некоторых данных.

мой опыт говорит, что в локалке потерь практически нет, а в интернете и tcp продалбывается. часами можно писать в сокет, который на той стороне отвалился давно. особенно на мобильном инете

В бинарных протоколах обычно предусматривают сообщения вроде ping, которыми переодически обмениваются клиент-сервер, как раз таки для контроля, что приолжение ещё живое

да, именно

Так если типа гарантии нужны может nats и иже с ними?

это сервер. в zmq, при том, что он говно, вот эта первая z очень полезная бывает

именно а если мы отправляем меньше, чем можем передать - и udp ок (в локалке). ну - для некоторых данных.

ну я ж писал, что udp норм если не страшно потерять

а если страшно - то и tcp не ок, надо на уровне приложения делать контроль

Зачем? Если хочешь протестировать неэкспортируемые функции протестировать, то нет

coverage... coveralls считает 78% в test пакете и всего лишь 36% в том пакете который test тестирует но это бред потому-что он должен учитывать coverage пакета из test вызовов

этот процент ценен только одним - возможностью отследить, что он не уменьшается

этот процент ценен только одним - возможностью отследить, что он не уменьшается

в смысле? просто на самом деле то библиотека протестирована на 78% а показывает мол 36%, неприятно))

да похрен же

да похрен же

да блин, красный бэджик на главной странице в 36% скорее пугает людей нежели обнадёживает.. а при том количестве тестов что уже написано это просто нечестно)))

так это

сделайте зелени

сделайте зелени

всмысле?

ну - напишите правильных тестов, чтобфы покрывали что надо

ну - напишите правильных тестов, чтобфы покрывали что надо

так уже написано всё, там более 75% уже проверено.. просто coveralls показывает неверные процент изза того что тесты и библиотека в разных пакетах

он же его не сам вычисляет

он его от go test получает

он его от go test получает

ну да, но ибо тесты в под-пакете он неправильный выдаёт coverage %

так это

написать как учат седые строгие отцы