- Ivy dependency - <dependency org="com.github.mrstampy" name="KitchenSync-core" rev="2.3.6"/>
- Example code
- getChunk implementation was overengineered in BufferedInputStreamStreamers, simplified.
- Improvements in ByteArrayStreamer
- Added ResettingLatch utility class.
- ChunkProcessor API change, streamer now supplied when determining header size
- bugfix in ByteArrayStreamer, automatic end of message sending fixed.
- Exposed throttling in ByteArrayStreamer.
- Removed explicit header reference from Streamer interface
- Added ChunkProcessor and Footer for transforming chunks and sending end of message messages, respectively
- Added a throttle for full throttle and acknowledgement messages to slow down throughput.
- Improvements to ByteArrayStreamer.
- Upgraded Netty to version 4.0.23.Final
- default chunk size for streamers increased to 2048 bytes
- added end of message functionality
- created ByteArrayStreamer for streaming byte arrays, tester class to demonstrate usage
- bug fixes for BufferedInputStreamStreamers which don't finish on empty streams
- bugfix, sent value not adjusted for header
- bugfix, unintended and unnecessary overrides in BufferedInputStreamStreamer
- better code organization
- Two new functions added to the Streamer interface, concurrent threads and header with sequence per chunk
- New StreamerHeader class for header specifics
- Increasing the number of concurrent threads greatly boosts performance, over 150 megabytes/second at full throttle and over 40 megabytes per second for acknowledgement messages
- Added Streamer architecture to stream arbitrarily large amounts of data
- Three modes of streaming - full throttle, chunks per second and ack required
- Two implementations: BufferedInputStreamStreamer and FileStreamer
- Test class to demonstrate usage
- Initial release
- Core functionality extracted from KitchenSync which now remains as a simple reference implementation
- Strong typing of abstract channels
KitchenSync-core is a Java Library for non-centralized network communication between separate processes using the UDP protocol. Channels can be created as multicast channels which allow broadcasting of messages to all connected channels, port-specific channels or next-port-available channels and are intended to be easily created and destroyed as required. It is built on top of Netty and is designed to be simple to understand and use while providing the ability to customise individual channels.
Two interfaces - KiSyChannel and KiSyMulticastChannel - provide the API for network communication. Three abstract implementations - AbstractKiSyChannel, AbstractPortSpecificKiSyChannel, and AbstractKiSyMulticastChannel - exist for ease of channel creation:
public class ByteArrayChannel extends
AbstractKiSyChannel<ByteArrayByteBufCreator, ByteArrayMessageInitializer, NioDatagramChannel> {
@Override
protected ByteArrayMessageInitializer initializer() {
return new ByteArrayMessageInitializer();
}
@Override
protected Class<NioDatagramChannel> getChannelClass() {
return NioDatagramChannel.class;
}
@Override
protected ByteArrayByteBufCreator initByteBufCreator() {
return new ByteArrayByteBufCreator();
}
}
The ChannelInitializer is a Netty class which is used to initialise a Bootstrap object for the channel and is ignored if the Bootstrap already exists. Netty channel handlers are added to the channel's pipeline in the implementation of the ChannelInitializer to control the channel's behaviour such as using SSL for connections:
@Override
protected void initChannel(DatagramChannel ch) throws Exception {
ChannelPipeline pipeline = ch.pipeline();
pipeline.addLast(new SslHandler(context.createSSLEngine()));
pipeline.addLast(new KiSyMessageHandler());
}
KiSyChannels can send and receive one of two types of messages by default - byte arrays and strings.
KitchenSync-core adds to the Netty architecture - which provides the ability to add custom handlers to interface with applications - by providing inbound and outbound message managers which are initialised on application startup to apply inbound and outbound application specific KitchenSync handler implementations to messages. This separates channel configuration (in the ChannelInitializer) from message processing such as logging of messages, persistence of messages, autonomous event triggering on message, etc. The handlers' execution is ordered to allow sequential operations to take place. Note that the handlers exist for preparation of messages for processing by the application and execution of any presend logic. Any significant processing of the message should be done on a separate thread. Strictly speaking only one implementation is necessary - inbound, to pull messages into the application.