java.nio cyclic buffer?

Networking & Multiplayer
#1

In order to decrease the byte-copying needed with non-blocking socket channels, I figured I could just write my own “PipeBuffer” that provides an InputByteBuffer- and OutputByteBuffer-view of the same underlying ByteBuffer. That buffer would be treated as a cyclic buffer

This would allow the client and server to just keep any unsent data from a SocketChannel.write() call to stay in the buffer without having to allocate a new buffer or move the remaining bytes to the start of the buffer.

Unfortunately, the constructor of ByteBuffer is package private, so that made me thing I’m probably attempting to do something I shouldn’t.
Does anyone have any better suggestions?

#2

Moving the remaining bytes to the front is done with buffer.compact() and I think that has lower overhead than housekeeping a cyclic buffer (always doing an index modulo). Just IMHO.

  • elias
#3

Ok, I’ll just forget about this nonsense.

Premature optimisation is evil, mmk? :wink:
deletes silly code

#4

:wink: There are many “optimisations” you can do with .nio… But they often turn out to make things worse instead :stuck_out_tongue_winking_eye:

#5

Hehe.

I keep telling people not to do this kind of pointless work, yet I always break down and do it myself from time to time. Heh.

I have to start trusting java more.

#6

[quote]Hehe.

I keep telling people not to do this kind of pointless work, yet I always break down and do it myself from time to time. Heh.
.
[/quote]
…but cyclic buffers are not merely an optimisation. They are a useful datatype in their own right. I have on several occasions been mightily annoyed by the lack of cyclic buffers in java…there are some algorithms which are just well-suited to using them.

#7

Yeah, optimising the networking in wurm wasn’t the only reason I wanted to make them… it also seemed like a fun thing to spend a couple of hours on.

Now someone explain to me why the ByteBuffer constructor is package private. :wink:

#8

i say just make it public,recompile and stick the class back into your rt.jar. :wink: