I would like to create a class that works much like a DefaultChannelGroup, but with the one difference that the message being written belongs to a connection and the channel associated with it will not have the message written back to it.
Think of the chat application where we should write to all other channels other than the one belonging to the user who wrote the message.
Looking at the implementation of the DefaultChannelGroup it seems I could add a new method named write that expects a given channel and the message, and will iterate the non-server channels and skip a channel that is equals to the given channel.
You could extend the DefaultChannelGroup to do as you outlined, but a channel group is already an iterator and set of channels already. If you already have a channel, you can perform ther write directly to it (i.e. you don't need to get it from the ChannelGroup), or, if for some reason, you really wanted to get it from the channel group, you could call ChannelGroup.find(channel.getId()).
I guess if you are doing this for the pruposes of narrowing down to a single channel, it's an issue of cosmetics. I am not pannning it.... personal preference ! If it makes it better for you, go for it.
The more interesting scenario, which would be a truly useful extension to the DefautChannelGroup, would be to assign individual channels a group of attributes encoded as a bit-mask. Then you might be able to do something like tell the BitMaskChannelGroup to write this message to all channels with a provided bit-mask argument, which might be the encoding for all chat-room users over the age of 21 living in New Jersey, or all routing devices where the manufacturer is Cisco.
Related
We are trying to read enOcean data from TCP.
The protocol description for enOcean ESP3-Messages says:
As soon as a Sync.-Byte (value 0x55) is identified, the subsequent 4 byte-Header is compared with the corresponding CRC8H value.
If the result is a match the Sync.-Byte is correct. Consequently, the ESP3 packet is detected properly and the subsequent data will be passed.
If the Header does not match the CRC8H, the value 0x55 does not correspond to a Sync.-Byte. The next 0x55 within the data stream is picked and the verification is repeated.
Until now we used a device (client) that automatically closes the connection to our server after the end of a number of messages coming within a very small timeframe (some milliseconds). Therefore we were able to use a simple ByteArrayRawSerializer. Whenever the connection was closed we got the byte array, read the data, found all the sync-Bytes and were able to interpret the messages.
Now there is a new device that is holding the connection for a very long time (several minutes), so we somehow need another way to read the data from the stream. Because there is no End-of-Message-Byte and the SyncByte 0x55 is part of the message and a ByteArrayLengthHeaderSerializer doesn't suit us either we wonder what we could use:
Is there any Deserializer usable for our scenario? Is it possible to writer our own Deserializer (in this specific scenario)? Or is there another (simpler) way we should follow? Maybe use an Interceptor?
You would need to write a custom deserializer.
I am implementing my own FAST handler/parser and some templates relies on a previous value of a field, like the copy operation that says: If not present, use the last/previous value received.
Every field has a reset method that clears the previous value of the field.
According to this link: http://jettekfix.com/node/44
You should reset the template after you process every message. Now that's a contradiction, in other words, how am I going to use the previous value of a field if I am resetting it after every message???
I must be missing something here. When should I reset the template parser?
This is not a contradiction if you take into account FAST sequences (i.e. FIX repeating groups). Most exchanges will reset the templates on each messages sent so a participant can join at any point. But inside the same FAST message, fields will be repeated inside a FAST sequence and that's when operations like copy come into play.
the link http://jettekfix.com/node/44 doesn't say you should reset the dictionary before processing each FAST message, but it does say you should reset it before processing each TCP/UDP packets, or after connection established. For example some exchange protocol have one UDP packet with multiple FAST messages bundled, you should not reset the dictionary in between.
I saw this description in the Oracle website:
"Since TCP by its nature is a stream based protocol, in order to reuse an existing connection, the HTTP protocol has to have a way to indicate the end of the previous response and the beginning of the next one. Thus, it is required that all messages on the connection MUST have a self-defined message length (i.e., one not defined by closure of the connection). Self demarcation is achieved by either setting the Content-Length header, or in the case of chunked transfer encoded entity body, each chunk starts with a size, and the response body ends with a special last chunk."
See Oracle doc
I don't know how to implement, can someone give me an example of Java implementation ?
If you are trying to implement "self-demarcation" in the same way as HTTP does it:
the HTTP 1.1 specification defines how it works,
the source code of (say) the Apache HTTP libraries are an example of its implementation.
In fact, it is advisable NOT to try and implement this (HTTP) yourself from scratch. Use an existing implementation.
On the other hand, if you simply want to implement your own ad-hoc self-demarcation scheme, it is really easy to do.
The sender figures out the size of the message, in bytes or characters or some other unit that makes sense.
The sender sends a the message size, followed by the message itself.
At the other end:
The receiver reads the message size, and then reads the requisite number of bytes, characters, to form the message body.
An alternative is to for the sender to send the message followed by a special end-of-message marker. To make this work, either you need to guarantee that no message will contain the end-of-message marker, or you need to use some sort of escaping mechanism.
Implementing these schemes is simple Java programming.
What makes a connection reusable
That is answered by the text that you quoted in your Question.
I'm writing an application server that will receive SIP and DNS messages from the network.
When I receive a message from the network, I understand from the documentation that at first, I get a ChannelBuffer. I would like to determine which kind of message has been received (SIP or DNS) and to decode it.
To determine the message type, I can dedicate port to each type of message, but I would be interested to know if there exist another solution for that. My question is more about how to decode the ChannelBuffer.
Is there a ChannelHandler provided by Netty to decode SIP or DNS messages? If not, what would be the right place in the type hierarchy to write my custom ChannelHandler?
To illustrate my question, let's take as example the HttpRequestDecoder, the hierarchy is:
java.lang.Object
org.jboss.netty.channel.SimpleChannelUpstreamHandler
org.jboss.netty.handler.codec.frame.FrameDecoder
org.jboss.netty.handler.codec.replay.ReplayingDecoder<HttpMessageDecoder.State>
org.jboss.netty.handler.codec.http.HttpMessageDecoder
org.jboss.netty.handler.codec.http.HttpRequestDecoder
Also, do I need to use two different ChannelHandler for decoding and encoding, or is there a possibility to use a single ChannelHandler for both?
Thanks
If you really have a requirement for port unification (an example here), i.e. receiving different protocols on the same port, then you would have to detect the protocol in a handler and take appropriate actions. Could be as simple as inserting different handlers in the pipe line.
However, I find it very improbable that SIP and DNS would share the same port, hence no need to complicate matters.
I haven't seen a SIP decoder/encoder for Netty, but depending on what you want to do with the message, the HTTP decoder is a a very good starting point (and could be made simpler since chunking is not supported in SIP).
I would strongly recommend not to try to combine DNS and SIP decoding in one handler (or any other combination for that matter). Keep the handlers as simple and coherent as possible. Combine handlers instead, if needed.
I want to write an application for my android phone to control it via wlan. That should contain its camera abilities.
Is there any elegant method to send live pictures and other information in one socket "at the same time"? My idea is to let the server accept more than one client: the first for life images, the second for information, third for audio streaming...
It should work like skype: you can call people and chat at the same time with one connection. How can I implement something like that?
I doubt multiple sockets would do you any good (unless Android makes it really hard to put data from multiple sources into the same stream). Just send everything sequentially in the same stream, with a tag in front to identify each type of data. The fancy name for this is "time-division multiplexing".
Multiple sockets might make sense if you get into fancy tweaking to, say, give more priority to realtime streams, but I have a feeling that shouldn't be necessary.