G
я слушай давно не работал с листеном, но почему у тебя protocoltype.ip? tcp или udp должно же быть, не?
Size: a a a
2018 July 03
D
я слушай давно не работал с листеном, но почему у тебя protocoltype.ip? tcp или udp должно же быть, не?
оказалась трабла в другом, контроллер долго не давал страницу
G
вот гад
D
Потому что пока оно сидит в Receive, все пляски с закрытием сокета, диспозом, добавлением флагов в его состояние, будут работать через пень-колоду - пока не примутся данные или не наступит таймаут приёма, всё будет где-то крутиться и оставаться открытым
какой адекватный таймаут для приёма?
АС
тут надо решить, с какой секунды считать, что на той стороне обрыв или тихое отсоединение и пора бы отсоединиться/пересоединиться
D
тут надо решить, с какой секунды считать, что на той стороне обрыв или тихое отсоединение и пора бы отсоединиться/пересоединиться
а если несколько потоков работают с одним листом, это может привести к большому потреблению ресурсов?
АС
сам факт существования лишнего потока, или двух или десяти, не делает погоды в потреблении ресурсов
АС
тем более что ресурсы бывают - потребление памяти, потребление CPU
D
тем более что ресурсы бывают - потребление памяти, потребление CPU
А когда мы принимаем в буффер байты, можно узнать до какого индекса были записаны данные, чтобы обрезать лишнее?
G
можно, метод длину возвращает
D
можно, метод длину возвращает
сломал себе логику если взять
buffer.Take(socket.Receive(buffer)).ToArray();
buffer.Take(socket.Receive(buffer)).ToArray();
D
мы же поидее получим новый массив нужной длинны с нужными битами
G
выглядит как г, наверное так же и сработает %)
D
если по дереву выражений будет выполняться
G
тебе переменную жалко?
D
buffer = buffer.Take(socket.Receive(buffer)).ToArray();
G
или ты перлист?
G
и линк не самая быстрая штука, я бы тейк тут не стал писать на всякий %)
D
и линк не самая быстрая штука, я бы тейк тут не стал писать на всякий %)
Тут больше спортивный интерес
D
и изучение особенностей языка