|
|
|
NIOSocketChannel read
|
|||
|---|---|---|---|
|
#18+
Коллеги подскажите плиз {code} int readBytes = socketChannel.read(buffer); if (readBytes == -1) { Что корректно делать тут ? Закрывать connection ? SocketChannel ? Или просто сбрасывать SelectionKey ? } {code} ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2014, 11:54 |
|
||
|
NIOSocketChannel read
|
|||
|---|---|---|---|
|
#18+
От ситуации зависит. Если клиенту нечего вам сообщить, то, вероятно, он ждёт вашего ответа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2014, 12:28 |
|
||
|
NIOSocketChannel read
|
|||
|---|---|---|---|
|
#18+
Но это не сигнал к тому что конекшен сдох ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2014, 13:55 |
|
||
|
NIOSocketChannel read
|
|||
|---|---|---|---|
|
#18+
Это сигнал к тому, что клиент сделал, как минимум, ShutdownOutput(). И больше ничего. Всё остальное определяется используемым протоколом и логикой приложения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2014, 13:58 |
|
||
|
NIOSocketChannel read
|
|||
|---|---|---|---|
|
#18+
buldozer01Но это не сигнал к тому что конекшен сдох? С фига ли? Если вторая сторона не шлет, данных, то почему обязательно "конекшен сдох"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2014, 13:59 |
|
||
|
NIOSocketChannel read
|
|||
|---|---|---|---|
|
#18+
Blazkowiczbuldozer01Но это не сигнал к тому что конекшен сдох? С фига ли? Если вторая сторона не шлет, данных, то почему обязательно "конекшен сдох"? Я пытаюсь понять чем отличаются -1 и 0 в возврате read ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2014, 14:00 |
|
||
|
NIOSocketChannel read
|
|||
|---|---|---|---|
|
#18+
buldozer01Я пытаюсь понять чем отличаются -1 и 0 в возврате read Прочитал доку. Я не прав. -1, действительно, свидетельствует о том что channel можно закрывать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2014, 14:05 |
|
||
|
NIOSocketChannel read
|
|||
|---|---|---|---|
|
#18+
Ноль - "нечего читать сейчас ". Минус раз - "достигнут конец файла". Во втором случае никаких данных более не может быть прочитано. В принципе не может. Ни одна из этих ситуаций ещё не означает, что надо всё бросить, не отписавшись в OutputStream ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2014, 14:05 |
|
||
|
NIOSocketChannel read
|
|||
|---|---|---|---|
|
#18+
Blazkowiczbuldozer01Я пытаюсь понять чем отличаются -1 и 0 в возврате read Прочитал доку. Я не прав. -1, действительно, свидетельствует о том что channel можно закрывать. Я ее тоже читал перед тем как сюда спрашивать ))) Вот не уверен я socketChannel надо закрыть или SelectionKey сказать cancel ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2014, 14:08 |
|
||
|
NIOSocketChannel read
|
|||
|---|---|---|---|
|
#18+
BlazkowiczПрочитал доку. Я не прав. -1, действительно, свидетельствует о том что channel можно закрывать.Да с чего вдруг??? У ТС SocketChannel с методами read и write и двусторонней коммуникацией, а не ReadableChannel и WriteableChannel по отдельности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2014, 14:11 |
|
||
|
NIOSocketChannel read
|
|||
|---|---|---|---|
|
#18+
Если что это код с сервера То есть клиент это не мы - мы сервер ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2014, 14:13 |
|
||
|
NIOSocketChannel read
|
|||
|---|---|---|---|
|
#18+
У клиента тоже просто socketChannel как клиент в коде может просто закрыть read если socketChannel один ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2014, 14:14 |
|
||
|
NIOSocketChannel read
|
|||
|---|---|---|---|
|
#18+
Повторю: shutdownOutput() ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2014, 14:16 |
|
||
|
NIOSocketChannel read
|
|||
|---|---|---|---|
|
#18+
Ну и не забывайте делать инверсию - клиент пишет то, что вы читаете . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2014, 14:17 |
|
||
|
NIOSocketChannel read
|
|||
|---|---|---|---|
|
#18+
В нашем коде такой метод не вызывается - зато есть if (socketChannel != null && socketChannel.isOpen()) { socketChannel.close(); } readHandler.shutdown(); writeHandler.shutdown(); ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2014, 14:19 |
|
||
|
NIOSocketChannel read
|
|||
|---|---|---|---|
|
#18+
Существует разница между "вашим кодом" и "кодом клиента". Мне, честно говоря, сложно представить ситуацию, когда клиент что-то отправляет серверу, но при этом не ждёт отклика. Почему бы не использовать тогда UDP? Но даже оставляя в стороне все эти изыски ... У вас есть данные, которые должны быть отправлены клиенту? Отправляйте и уже потом "тушите свечи". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2014, 14:22 |
|
||
|
NIOSocketChannel read
|
|||
|---|---|---|---|
|
#18+
Хорошо буду откровенен Копаю HazelCast и пытаюсь понять какого хрена через раз закрываются конекшены Добавил дебаг - чуваки ловят -1 и закрывают socketChannel Теперь вот пытаюсь выяснить это хазелькаст валидно закрывает конекшены на клиенте или просто это говнокод и socketChannel можно и не закрывать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2014, 14:26 |
|
||
|
NIOSocketChannel read
|
|||
|---|---|---|---|
|
#18+
Ну кретины, что скажешь ... Сокет - механизм двусторонней независимой коммуникации. Получив признак конца файла при чтении данных, вы должны обработать принятое, отправить данные клиенту и только после этого гасить соединение. Можно "за раз", можно "по разделениям". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2014, 14:34 |
|
||
|
NIOSocketChannel read
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovНу кретины, что скажешь ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2014, 14:35 |
|
||
|
NIOSocketChannel read
|
|||
|---|---|---|---|
|
#18+
Чуть конкретизирую. У приведённого кода есть проблема. Если клиент: 1. Отправляет запрос 2. Принимает отклик 3. Закрывает соединение то закрытие канала сервером происходит на шаге три, что корректно и даже необходимо. Если клиент: 1. Оправляет запрос 2. Закрывает канал записи; 3. Принимает отклик 4. Закрывает канал чтения то закрытие канала сервером происходит на шаге два и является ошибкой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2014, 14:50 |
|
||
|
NIOSocketChannel read
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovЕсли клиент: 1. Отправляет запрос 2. Принимает отклик 3. Закрывает соединение то закрытие канала сервером происходит на шаге три, что корректно и даже необходимо. А можно теоретический вопрос? А как "закрывает соединение" физически дойдет до сервера? Я правильно понимаю, что вместо одного сетевого round-trip's "запрос клиента-ответ сервера" по сети пойдет минимум два "запрос клиент-ответ сервера-запрос на закрытие соединения....и так далее...." ? Для общего развития, совсем слабо представляю, как соккеты поверх пакетных протоколов работают ((( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2014, 15:40 |
|
||
|
NIOSocketChannel read
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevА можно теоретический вопрос? А как "закрывает соединение" физически дойдет до сервера? На сколько я помню предыдущее обсуждение по теме, "закрытие" оно между клиентом и сервером никак не "ходит". Можно только по таймауту отвалиться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2014, 15:45 |
|
||
|
NIOSocketChannel read
|
|||
|---|---|---|---|
|
#18+
Leonid KudryavtsevА можно теоретический вопрос? А как "закрывает соединение" физически дойдет до сервера?Во флагах (последного) отправленного клиентом TCP-пакета.Я правильно понимаю, что вместо одного сетевого round-trip's "запрос клиента-ответ сервера" по сети пойдет минимум два "запрос клиент-ответ сервера-запрос на закрытие соединения....и так далее...." ?Нет. После того, как соединение установлено, число пакетов , которыми обменяются клиент и сервер, зависит от объёма передаваемых данных и характеристик канала. Проблема round-trip - несколько из другой серии и, как правило, связана с конкретным протоколом. Насколько я помню, TCP может подтвердить всё полученное единственным пакетом. Остальное зависит от размеров окон и качества канала. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2014, 16:02 |
|
||
|
|
start [/forum/topic.php?fid=59&msg=38691921&tid=2126922]: |
0ms |
get settings: |
9ms |
get forum list: |
24ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
191ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
| others: | 249ms |
| total: | 548ms |
| 0 / 0 |
