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

тоесть с accept так и оставить через try-catch?

Ну continue не надо делать

а как понять что соединение отошло?

Сейчас получается у тебя по тихому ошибка гасится и все

Ну continue не надо делать

эт я уже понял, меня смущает логика на исключениях

auto res = sock.receive(buf[readed .. $]); if (res == Socket.ERROR) { if (errno == EAGAIN) res = 0; else throw new Exception("TCP Socket receive error " ~ errno.to!string); }

Вот это непонятно что, смешал высокоуровевые сокеты std и libc linux

Вот это непонятно что, смешал высокоуровевые сокеты std и libc linux

да блин! я ж говорю, что не понимаю как норм сделать)

Убери errno, пользуйся для получения ошибки тем что предлагает std.socket

Убери errno, пользуйся для получения ошибки тем что предлагает std.socket

сравнивать строку ошибки с "Success"

как понимаю

Должны быть константы )

А ты делаешь без select ?

Почему бы его туда не приплести

Каждый раз как добираешься до чтения из сокета - добавляй его в SocketSet и делай select()

Если там пусто то и читать нечего.

так а select не станет блокировать?

нет

А, понял о чем ты

так а select не станет блокировать?

ну, наверное, если таймаут 0, то нет

Да, наверное стоит select() сам по себе сделать как-то неблокирующим

Дело в том, что я не понимаю( Можно пример, как сделать select неблокирующим?

Дело в том, что я не понимаю( Можно пример, как сделать select неблокирующим?

Селект сам по себе не блокирующий

Блокирующий

Его вызов будет блокирующим только если передавать ему блокирующие сокеты

Или один из списка будет блокирующим

О_О_О_О_О

вот это поворот!

Если передавать не блокирующий сокет - он не блокирующий

Думаю что это не так )

А ты проверь

так а можно просто ссылку на документацию?

https://dlang.org/library/std/socket/socket.select.html

Wait for a socket to change status. A wait timeout of Duration or TimeVal, may be specified; if a timeout is not specified or the TimeVal is null, the maximum timeout is used. The TimeVal timeout has an unspecified value when selectreturns.

Если тайм 0, то возвращает те сокеты, которые имеют данные на вход или готовы для записи

так это у меня и открыто. Но тут ничего про блокируемость сокета в сете ничего не сказано

А если не 0, то он будет ждать событий до таймаута, даже на всех неблокирующих сокетах

поэтому моему удивлению не было предела

The timeout argument specifies the interval that select() should block waiting for a file descriptor to become ready. The call will block until either: * a file descriptor becomes ready; * the call is interrupted by a signal handler; or * the timeout expires. Вот надо читать первоисточник )

http://man7.org/linux/man-pages/man2/select.2.html

The timeout argument specifies the interval that select() should block waiting for a file descriptor to become ready. The call will block until either: * a file descriptor becomes ready; * the call is interrupted by a signal handler; or * the timeout expires. Вот надо читать первоисточник )

А если сокет не блокирующий, он готов всегда!

Нет не готов

Есть такое понятие как событие, возникшее на сокете

Просто возьми и попробуй. Я с телефона.

А что изменится? Я пробовал уже года полтора назад, сейчас неохота.

Можно сделать в консоли перед и после select() вызовы writeln("Waiting for data..."); select(...) writeln("Data received, processing"); И он остановится после первого writeln

Если бы он был блокирующим то во первых он бы бесконечно выводил строки в stdout а во вторых жрал бы процессор на 100%

Если бы он был блокирующим то во первых он бы бесконечно выводил строки в stdout а во вторых жрал бы процессор на 100%

Нет

Блин, сам скоро проверю

Так, а с каким timeout проверять?

0 как я понимаю, не станет ждать изменений в сокетах

Ну поставь 1 секунду

Ну ок

select возвращает дескрипторы, операции ввода-вывода на которых не будут заблокированы. т.е. что бы прочитать что то - не надо ждать. 0 - проверит и сразу вернется, > 0 - либо вернет дескрипторы, либо по таймауту выйдет, null - ждать до последнего. Вродеж все написано в манах, парни_

Да я не знаю че он говорит что селект неблокирующий

да и нафиг он не нужен тут. сокеты в неблокирующем режиме ж, есть даже спец метод bool wouldHaveBlocked() nothrow @nogc { version(Windows) return _lasterr() == WSAEWOULDBLOCK; else version(Posix) return _lasterr() == EAGAIN; else static assert(0); }

всё-таки майкрософт купил гитхаб? пиздец котёнку.

Так непонятно, пока select не работает, сокет может что-то принять и следующий select это покажет?

всё-таки майкрософт купил гитхаб? пиздец котёнку.

А что такого?

Так непонятно, пока select не работает, сокет может что-то принять и следующий select это покажет?

Да

Вроде понял

Да я не знаю че он говорит что селект неблокирующий

Ну так передай тайм-аут 0 и он не блокирующий

Ну так передай тайм-аут 0 и он не блокирующий

Зачем тогда все эти твои аргументы про блокирующте сокеты? Его поведение вообще не зависит от того какие сокеты он слушает

Если селектить блокирующий сокет с таймаутом 0 то селект все равно сразу вернется и ждать ничего не будет.

Как доберусь до компа - сделаю тест

складывается впечатление, что работа с сокетами мало чем отличается от работы с ком-портом

ERROR: S client not available

select тот же, read/write те же

MS шикарно троллит https://pbs.twimg.com/media/DerxhrEWsAYQsa7.jpg

а линкедин тоже МС?

купили ну

кмк это фейк )

Бот вроде снова стал выплевывать пакеты махом

Бот вроде снова стал выплевывать пакеты махом

он всегда так делал - телеграм блочат а туннель ипв6 виснет. когда я перезагружаю комп всё восстанавливается на некоторое время

сраный РКН

deviator/serialport крутой логотип запилил

https://forum.dlang.org/post/pf5bj1$n5h$1@digitalmars.com

deviator/serialport крутой логотип запилил

спасибо)

складывается впечатление, что работа с сокетами мало чем отличается от работы с ком-портом

но! как я понял receive никогда не возвращает 0, если есть соединение в неблокирующем режиме возвращается -1 (Socket.ERROR) если нет данных то есть 0 прочитанных байт как сигнал к закрытию соединения

0 - другая сторона закрыла соединение

0 - другая сторона закрыла соединение

ну да, но ведь со стороны сервера этот сокет можно уже закрывать и ждать новый, правильно?

этот же сокет больше не может быть использован

ну как бы да, ибо ты больше по нему ничего не примешь)

значит вроде разобрался

нет... чёт не до конца видимо разобрался

listen это что есть?

не общее количество соединений?

ну типа максимальное

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

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

я так понимаю, имеет значение, если запросы прут чаще, чем твоя программа успевает их принимать accept-ом

но это не максимальное количество соединений, да

нехватка базовых знаний ударила по голове... этим моментам в вузах каких-нибудь учат? или вузы только для фундаментальных знаний?)

типа физика, математика, алгоритмы...

В хороших вузах учат, курс называется типа "Архитектура операционных систем"

И там где-нибудь есть пару лекций про то как работают сокеты

в хороших забугорных вузах на специальностях типа CS много чему хорошему учат вроде как) хотя и у нас много прям хороших лекций по алгоритмам и структурам данных

нехватка базовых знаний ударила по голове... этим моментам в вузах каких-нибудь учат? или вузы только для фундаментальных знаний?)

проще самому, имхо

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