В общем сижу я и жду данные:

а в другом треде эти данные отсылаю, вот так:

И ничего не работает, а вот если out.close() раскомментировать, то всё работает.
Почему так?
Зачем мне вызывать out.close() чтобы данные дошли? разве flush недостаточно?

Исправлено: sikee8, 09.12.2006 22:00

Зачем мне вызывать out.close() чтобы данные дошли? разве flush недостаточно?
flush вполне достаточно для того, чтобы данные дошли и прочитались из InputStream (Socket.getInputStream()). Но у Вас вокруг InputStream обернут еще и BufferedReader, который при чтении строки делает следующее:Ну а так как в записанных данных не встречается переводов строки, BufferedReader спокойно ожидает чтения следующего символа (или конца потока данных).
DataOutputStream вокруг client.getOutputStream() в данном примере лишний, можно было сразу в client.getOutputStream() писать packet. Кстати, Вы уверены, что строку нужно выводить через DataOutputStream.writeUTF а читать с помощью BufferedReader.readLine()? Или пара лишних символов в начале строки Вам нужна?
И по коду сервера - а может assertNotNull должен стоять до if(kkk.length()>0)...? А то в случае kkk==null до assert'а дело не дойдет.
Кстати, с темой не угадали, вопрос то про BufferedReader

Maxim Karvonen

спасибо за такой подробный ответ! теперь я всё понял
BufferedReader это я уже написал, вообще сначала хотел делать DataInputStream.readLine, но оказалось deprecated зато любезно предоставили строчку для копипейста с буфередридером, ну я собственно и копипейстнул

Кстати, Вы уверены, что строку нужно выводить через DataOutputStream.writeUTF а читать с помощью BufferedReader.readLine()? Или пара лишних символов в начале строки Вам нужна?
Нет, конечно так не должно быть, просто пока хотелось проверить что что-то работает, не особо задумываясь о мелочах Та часть кода которая совсем срашная не мной написано
а может assertNotNull должен стоять до if(kkk.length()>0)...? А то в случае kkk==null до assert'а дело не дойдет.
да нет ассерт стоит там где нужно, хотелось просто чтобы тест обломался а сообщение об ошибке я юзаю как дебагинформайшн вот break там не к чему конечно

Добавление от 11.12.2006 15:06:

ещё один вопрос.
в общем я стал использовать DataInputStream.readFully, но он

This method blocks until one of the following conditions occurs:
* b.length bytes of input data are available, in which case a normal return is made.

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

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

Смотри метод Socket.setSoTimeout().

С ним есть одна проблема. Вы не можете ручаться, что Вам действительно придет весь объем данных, который может вместить массив. И тогда либо по таймауту вываливаться, что не есть хорошо, либо висеть.

Проще читать просто массивом, анализируя, сколько считано. Во-первых, не блокируется. Во-вторых, всегда можно понять, что поток кончился - read вернет -1.

Hedin

спасибо, помогло

Skip

Моя задача была проверить что что-то пришло. В моей ситуации это самое большее что я могу сделать, поскольку метод не специфицирует формат сообщения. Поэтому я объявил byte[1] и передал его в readFully, если хотя бы один байт дошёл - ура. Если нет вываливаемся по таймауту в SocketTimeoutException и там говорим fail.

Ещё одну странность нашёл

Конструктор ServerSocket переводит в LISTENING state, если ему указать порт.
Вот смотрите, запустил вот такую программу:

а потом сделал вот так:

netstat -na | grep 23459
*.23459 *.* 0 0 49152 0 LISTEN
~;

Вопрос, ЗАЧЕМ нужен метод accept? Ведь это он:

Listens for a connection to be made to this socket and accepts it.

Тогда я решил проверить, а можно ли отсылать данные на сокет на который не было сделано accept?

И оказывается можно. Их можно не только отсылать, можно ещё и получать. Вот он, аутпут:


Вот лично для меня несколько странно что сокет сразу весит в listening state, тогда как это, на мой взгляд, должен делать accept. Почему так всё странно?

sikee8
Почему так всё странно?
Все не странно, а так и задумано. Если указываешь [адрес, очередь, ] порт при создании сокета, он автоматом биндится.
Сделано это для тех сокетов, которые нельзя создать в незабинженом состоянии. Т.е. при попытке согдать его (такой сокет) без параметров получишь эксепшен. Например так поступают некоторые реализации SSL.

Венгерович Михаил

Как всё странно
Тогда уж в описании функции accept:
Listens for a connection to be made to this socket and accepts it.
нужно добавить
Listens (if not already listening) for a connection to be made to this socket and accepts it.
А то как-то путанно получается...

sikee8
Вообще LISTEN сокет на более низком уровне это сокет проверяемый на чтение (собственно, да, Вы можете туда писать ). Внешнее воздействие приводит к постановке в очередь запроса на соединение. Для большинства систем по умолчанию размер очереди равен 5 запросам. Реальное соединение устанавливается во время исполнения функции accept(). CONNECT сокет при этом (при установлении соединения) переходит в состояние "доступен на запись". А LISTEN сокет так и остается "слушать", то есть через один слушающий сокет Вы можете установить множество соединений.

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

вот этого я и не понимаю, КАК я могу писать в сокет, который НЕ НАХОДИТЬСЯ в состоянии CONNECT
Насколько я помню, у нас тройное рукопожатие идёт (кажеться)
Ну в общем суть в том что сначала
1. Сокет вешается в LISTENING
2. С удалённого хоста идёт запрос на конект
3. Отсылается подтверждение коннекта, при этом по идее должен сообщиться номер TCP пакета(вообще там два номера вроде, SYN и ACK, один в одну сторону, другой в другую)

Кароче суть в том что написать в сокет который просто находиться в LISTENING state, невозможно, просто потому что нету необходимых для TCP соединения чисел (SYN и ACK).

Вообще я так думаю что тут другой артефакт произошёл, все эти данные закэшировались, а реально отправились только после acceptа.

В общем для меня странно одно, то что ServerSocket вещается в listening state без вызова accept - кому и зачем понадобилась такая функциональность - для меня загадка. Надо мне создать сокет - я создам. Надо повесить в listening - я вызову accept.
А так получается создал ServerSocket, он повис в листенинг, туда народ будет конектиться, а я например accept так ни разу и не вызову. И что получаеться? Получается что зря конектились. У них заведома не было ни одного шанса. Но зачем тогда переводить сокет в LISTENING? Непонятно. А мне вот довольно сложно по назначению использовать непонятное API, а приходиться.

ServerSocket service = new ServerSocket(23490);
Просьба OS при зарезервировать порт 23490 за точкой доступа описываемой возвращаемым сокетом (service). Указаний о том что делать с пакетами поступающими в адрес этого порта нет. С другой стороны с этого момента порт связан с сервисом (серверным сокетом) и когда то позже от него поступят указания что с ними делать . Поэтому OS принимает все запросы на соединения с сервисом а пакеты поступающие по ним откладываются в буфер приема и будут обработаны сервисом позже когда он сможет. Если бы порт не был зарезервирован то пакеты обрабатывала сама OS отказывая в соединении NAC и посылая запрос разрыва соединения при поступлении данных по соединению о существовании которого она не знает. А так ответственность за то что делать с данными зарезервировало за собой приложение создавшее серверный сокет - OS стоит в сторонке и просто буферизует данные для приложения (не до бесконечности само собой)
...
Socket serviceSocket = service.accept();
Приложение сигнализирует OS о том что оно свои дела сделало и готово заняться очередным соединением (и его данными) которые для него OS для него подготовило. Несмотря на то что клиенты коннектелись в произвольные времена в том числе и в те моменты когда серверная нить исполнения принять заняться соединением не могла - соединение было принято и сервер имеет возможность его данные обработать.

Ну а теперь представим на секундочку что API вдруг сделали "логичным" как Вы предлагаете - то есть все запросы установления соединения вне времени ожидания в вызове service.accept() идут лесом - домашнее задание подумать что будет с двумя последовательными вызовами идущими с разных хостов поступившими практически одновременно. Правильно один из них пришедший в момент когда серверная нить исполнения вышла service.accept() и занимается первым запросом идет лесом без объяснения причин. На гневный вопрос клиента "а почему собственно, а какого?" сервис удивленно говорит "а был мальчик? собственно!" мне о вашей попытке со мной связаться ничего неизвестно - Ну правильно в таком API ее отвергли даже не уведомляя сервер. По причине что именно в эту миллисекуду когда поступил запрос, серверу его не ждал и другими делами занят. А эти другие дела после выхода из service.accept() ой какие не быстрые могут быть. Пусть эти другие дела занимают 1 секунду (кошмарно большое время для принимающего соединение кода). Тогда сервис способен обработать 60 запросов в минуту НО если они поступают не чаще чем раз в секунду - Бред посчитай сам эффективную скорость обработки при случайном равномерном распределении запросов клиентов по времени с средней частотой 60 запросов в секунду. Независимые клиенты в сети синхронизовать свои запросы не имеют ни каких шансов и прогнут сеть своей настойчивой долбежкой к северу который постоянно их посылает. Нет уж пусть будет такой как сейчас - создал серверный сокет значить объявил о существовании сервиса на порту XXXX к которому можно посылать запросы. И пока средняя частота запросов на соединение не превышает возможностей сервера для их приема клиенты могут обращаться в произвольном порядке и с произвольной частотой OS обеспечит буферизацию и выравнивание загрузки по времени.

Счастья всем и пусть никто (и клиентов) не уйдет обиженным. Если возможности сервера по полноценной обработке запроса будут исчерпываться - нормально написанный сервер просто закрывает невозможные к обработке соединения (осознанно а не потому что случайно в момент поступления запроса другим был занят – то есть по факту обрабатывает все соединения - часть нормально, часть "варварским" способом. И это логично - взялся работать сервисом работай. А если ни разу accept() не вызвать OS сама закрое все принятые соединения по этому порту – по факту "варварски" обработав запросы клиентов. Но по любому это решение обработать нормально или послать принималось сервером толи тем что он сам закрывал принятый сокет, толи тем что приказал закрыть все принятые закрыв серверный. Но никакой отсебятины OS пока сервис был определен на порту не несла.

WBR CrazyElk

CrazyElk

спасибо большое за объяснение, теперь осознал
насколько я понял если я делаю new ServerSocket, потом жду скажем минутку, за эту минуту ко мне приходят скажем пять запросов на коннект. Если после этого я сделаю пять раз srevice.accept(), то все пять acceptов вернут сокет немедленно. И это будут те 5 сокетов которые уже давно находятся в состоянии connect.
Если так то теперь мне совсем до конца всё стало ясно

sikee8
Если только те клиенты по собственным тайм-аутам не отвалятся за эту минутку

Когда пишешь код, иногда полезно прикинуть, что у тебя "зависон" (e.g. дикий своп) секунд на 10 между каждымим подряд идущими строчками (а по сути - между каждой парой asm инструкций на уровне железа). При чём то 8, то 12 - т.е. непредсказуемые такие паузы Тогда все синхронизационные заморочки - как на ладони (особенно с потоками подобное "мышление" помогает). А OS этих зависонов лишена потому что она реагирует на поступающие коннекты в kernel mode - т.е. процессор "мгновенно" прерывается по прибитию пакета на сетевую карту (на уровне IRQ линий железа, никаких периодических опросов) и пакет "немедленно" же обрабатывается ("немедленно" - зависит только от скорости процессора). User mode код (твой код) лишён этой првелегии - поэтому кушает то время, которое есть. Хоть по такту в час. Т.е. "подряд идущие" команды на уровне Java, C++, etc... могут оказаться далеко не подряд идущими относительно всего чем занят процессор. Да - относительно друг-друга они всё еще будут подряд идущими. Но только относительно друг-друга. А в реале это может минутами оказаться. Я это всё к тому, что твоё "заблуждение", вероятно, спровоцировано мысью о "моментальном" исполнении цикла с accept'ом. Это не так.