Здравствуйте, уважаемые. Сделал чтец сообщений из сокета.

Но беспокоит оптимальность работы с БайтБуффером:
1. Расширение буфера.
2. Возможно есть лишние операции buffer.rewind(); buffer.flip(); buffer.compact();

Platon, тут надо сначала пояснить, как размер сообщения определяется. Он может в начале сообщения присутствовать. Тогда, прочитав первые байты сообщения (например, все сообщения имеют в первых 4 байтах свой размер - только ваша int amount может быть равна и 1) можно узнать размер и создать буфер под сообщение фиксированного размера. Второй вариант - используется маркер конца сообщения в виде спецсимвола. Этот вариант обычно работает при передаче строк.  Тогда буфер под сообщение создается динамический, например, List. А других вариантов и нет.   

Другие варианты есть.


Говорит нам о том, может ли содержимое буфера содержать по крайней мере 1 сообщение, не важно как оно помечается, это уже внутреннее решение декодера. Единственное, этот декодер возьмет из буфера данных столько, сколько ему нужно, и не больше!

По сути дела надо поковыряться в искходниках Apache MINA там эта штука хорошо реализована. Сравнивая с текущей версией моего сокет ридера MINA гораздо быстрей читает сообщения. Проверял на передаче изображения 4Мб MINA читает практически мгновенно, мой ридер, немного думает.

Есть третий вариант. Передать сообщение и закрыть соединение. Тогда концом сообщения будет выполнение условия if (amount == -1) .



а декодер-то чем руководствуется? Если вы передаете сырые байты (не char или какой-то другой ограниченный набор байтов), то вариант только один - в начале сообщения должна быть информация о сообщении, из которой можно определить его длину. А раз длина сразу известна, то нет необходимости реккурентно увеличивать буфер:


Если у вас по одному байту будет читаться (amount = 1), вы по одному байту будете буфер наращивать.

Это сообщение отредактировал(а) COVD - 28.2.2008, 18:08

COVD, мы сейчас решаем не эту проблему ^_^ декодер мы не трогаем, он сам разберется, какая там структура.

Я попробовал порыться в дебрях MINA, так и запутался в дебрях... Буфер Mina работает шустрей чем мой, факт остается фактом.
Мне важно понять где тормозит мой ридер?

 

на мой взгляд, в ненужном промежуточном buffer. 

Вот этот имеете ввиду? а как же мне принимать данные иначе?

нет, buff - это основной, куда вы читаете из сокета. Потом вы все копируете в buffer. При этом, если не хватает места, то увеличиваете его.  На этом, наверное, и теряете. 

Насколько я понял, buffer - просто промежуточный, т.е. возможны ситуации, когда в buffer лежат одновременно несколько сообщений (если они короткие), и одно неполное (если сообщение длинное). На мой взгляд - это не нужно. Поскольку сообщения передаются всегда последовательно (а не так, что сначала несколько байт одного, а потом несколько байт другого), то проще под каждое новое сообщение создавать новый буфер. Тогда если сообщения неопределенной длины, т.е. конец определяется спецсимволом - только в этом случае придется динамически размер буфера наращивать. Если же передаются сырые байты, то длина сообщения будет известна вначале и буфер под это сообщение можно сразу создать. Думаю, что так и делаете в своем декодере, но при этом имеете промежуточный перевалочный пункт в виде buffer.