I have a problem sending concatenated messages to my SMSC, here, I will do my best to describe the problem.
When sending concatenated messages, my SMSC waits to receive all the segments of the message and then processes it to the provider and sends back the response, this means that when using the JSMPP java lib, whenever I receive a long message (more that 160 chars for GSM7) I will split the message into segments and submit each segment using the session.submitShortMessage method.
The problem is that this call is synchronous and waits for the SMSC to respond with submit_sm_resp. Therefor I need to use some sort of async mode to submit the messages.
I have no idea on how to do this with the current implementation of the library.
Do you know any way of doing this?
Thanks in advance
The way you have described SMSC is working in your case seems suspicious to me. I don't know of any SMSC that would only respond back once all segments have been submitted (here I am assuming the communication via smpp protocol). Considering your SMSC implements smpp specification version 3.4, you might need to talk with the team responsible for maintaining this SMSC.
Suppose your (jsmpp) client splits a long text message (more than 140 bytes) into two segments. For each segment, your client sends submit_sm and receives synchronously submit_sm_resp. This is the correct client side behaviour and can be seen one of the examples (SubmitLongMessageExample.java) from jsmpp library.
The example uses optional parameters when submitting the message to the SMSC, providing sequence number, total segments and most importantly, a unique message reference number.
The SMSC, should principally, synchronous respond back for each submitted segment and when it determines that for a unique message reference all segments has been received, it should then process the message and deliver it to the end user (mobile phone).
This behaviour/information can also be found in the specification at https://smpp.org/. If your SMSC does not behave like this, then the standard implementation by jsmpp library cannot help you (and for that matter anyone else)
You need to use the transciever bind-mode and use an implementation of the MessageReceiverListener onAcceptDeliverSm.
Related
let's say I have a REST endpoint that does this:
Receives a json body, do some mapping and then send the message via a messaging producer. (RabbitMQ)
The producer is async.
I have a consumer for the producer in 2 that will do some business logic and post a reply.
Now, I need to receive a reply after some interactions in my rest endpoint.
As the client of my rest call is expecting a reply, the solution that comes to mind is to have the endpoint listening on reply queue with a short timeout, so that I can return the response via REST.
Am I thinking the right way or should I just have a blocking producer and use RPC like it is stated here: https://www.rabbitmq.com/tutorials/tutorial-six-java.html
I want to find the most optimal solution.
Note: I'm not using Spring as I'm learning all these concepts to have a clear understanding.
Producing on queue from an HTTP call on server is fine.
Waiting for a queue and and replying for HTTP call on its response is not preferred way.
A reply queue may have many messages on it. What happens if your consume a message meant for different client call? Do you pass the message to appropriate consumer? How do you find out appropriate consumer? You may re-enqueue the message which is wastage of cycles. A message may stay on queue forever.
If request queue is flooded and you may have to poll many times to get your result. If you receive reply before client polls you would need to store reply so that you can pass it to client on next call.
These are just scratching the surface of the problems that may arise. If your client is really an HTTP client, you can use above to cover important bases of your application.
A better solution would be to write a consumer on reply queue which would call some endpoint on consumer. However it would still require you to consider cases like failures and retries both on server and client side.
I didn't answer your question but gave you some points to think about. Please don't mark this as accepted answer.
I know this is an old but if someone is still looking for this. This is mostly related to RPC in rabbitmq. One way could be to set Correlation ID on each produced message (on consumer you receive this Correlation ID and you can match it back), then check if that's the one you are expecting. You set it to unique value (UUID for example) on each request and compare to see if that's the response you are expecting back.
There is also a feature called Direct Reply-to explained nicely: https://www.rabbitmq.com/direct-reply-to.html
The producer consume from "amq.rabbitmq.reply-to" and produce with ReplyTo property set to "amq.rabbitmq.reply-to", while the consumer once received and processed message reply to the messages "ReplyTo" property as routing key and empty exchange.
Hope so this helps someone in future.
I am using UDP Socket programming in java and need to send data over a noisy bridge.What i have done till now is the client is sending the message to servery but as i told the bridge contains some noisy so what should i do to send successfully message. I am giving code of Bridge. Can anybody help.Thanks in advance
In short, I would
Send a negative acknowledgement when a gap in the sequence numbers is sent.
I would resend much more often, up to the point that the line saturates. Possibly resend after 100 ms or less.
If the data is short, I send two pieces of data in a packet to increase the chances of it getting through.
I would send an acknowledgement which implies that a range of values are acknowledged e.g. everything up to that point, for cases where the acknowledgement is corrupted.
I am trying to communicate between two computers using the Serial port and I am new to this area. I need to send requests from one computer(say A) to the other(say B) and receive responses for the requests sent. I am updating a Java Swing user interface with the responses.
I am using the jSSC library to do this. I have looked at the SerialPortReader examples and following is my understanding.
I will have to implement the SerialPortEventListener on both computers.A will use the writeBytes method to send the requests. B will listen to the commands sent using the SerialPortEventListener and will use the writeBytes method to send the response. A will listen to the data using its implemntation of SerialPortEventListener and when data is recieved, will update the UI. The following are my questions.
a) Is my above observation correct? Is there a different way to do this(for example is it possible that a writeBytes method that will return the response exists within the protocol?)
b) I read in several paces that serial port communication can be either synchronous or asynchronous. But from the examples, I can't understand if that code has implemented an asynchronous or synchronous communication. How would one go about implementing synchronous/asynchronous communication using jSSC? I am not asking for an implementation. Just some guidelines and what methods can be used.
c) It's possible that messages will be partly delivered. For example, if I send the command as a String "get variableThreeValue", it is possible that only the "get" or something like "get varia" will be received.(this can result in messages like "get get" etc..) How can I handle this kind of scenario? Again, I am not asking for an implementation. Just some guidelines and what methods can be used.
A classic "serial port" is something very "low level". Parameters like baud rate, start and stop bits and flow control must be set, and then byte sequences are read and written. The Java library uses a listener to receive events which are directly derived from what the serial driver senses (you find terms like "line" in the javadoc). How to react, depends on "the other side".
Flow control is what you use to avoid overrunning or overfilling the receiver. The lines of an RS-232 contain C(lear)T(o)S(end) and R(equest)TS, so "hardware handshake" is one option. Alternatively, US-ASCII defined control characters XON and XOFF which could be embedded in the data stream if it is not binary data. Flow control should not be an issue if the sending end doesn't send at full blast or computers differ significantly in speed.
As I understand, you'll connect some radio device to the port, and its documentation should specify all the parameters, and also the higher level protocol, i.e., how to transmit and receive data. The device may have special requirements, e.g., that you must pass on some setup data before you transmit actual data. (If you connect two computers with just a cable, then everything is up to you.)
Once you can basically send and receive, you'll have to think about safe transmission. You need to design a protocol:
message format, e.g. containing a length, a sequence number, data bytes, a CRC.
message sequencing, i.e., who may send what and when, e.g., a message A to B, an acknowledge from B to A, repeat. Or a NAK from B, and A must resend.
Perhaps you need a "session protocol", i.e., a login (as in ftp) and a logout
Timeout: what if either side doesn't receive another message within T?
Do you need a heartbeat, i.e., a message sent when the channel is idle to learn that the other side is still "alive".
A WLAN connection should make most of this unnecessary. Real "radio" (some short wave?) I've never heard of, but I'm not a radio expert.
XON/XOFF is software flow control. Assume bi directional serial bytes between producer a and b. If either sends a XON byte it means whoa, stop sending me bytes until I send you a XOFF byte.
For hardware replace XON byte with CTS and XOFF byte with RTS.
I'm developing a websocket application by using Netty. I'd like to know if a message is really delivered from a source to a destination. In particular, let's assume that a client and a server have an open channel and exchange some messages for a while. At a certain point, the client goes down, but the channel is still active in Netty. I tried to use isReachable() before sending the message, but this method seems to be buggy in some scenarios (e.g. a machine with Win7 is up, but isReachable() returns false). Now, my idea is to implement a mechanism using ACKs, namely the server sends the message and the client sends back an ack. To do that, I need a timeout to see if, after a certain interval, the corresponding ack does not arrive. Is there something similar in Netty?
Regarding isReachable() - it's only a best effort API. The documentation points out that it tries to send an ICMP echo request or create a TCP connection to port 7 on the destination host, both of which are highly likely to be blocked by a firewall. Is this happening in your case?
As for the acknowledgement, there's nothing in Netty that provides this as standard, but it shouldn't be too difficult to implement. Firstly each message needs to be uniquely identifible by some sort of identifier, possibly a sequence number but a globally unique identifier means you can potentially recover across disconnections. Then you want to create a combined handler that implements both ChannelInboundHandler and ChannelOutboundHandler (assuming Netty 4). When a message is sent
add the message to a map indexed by its id
create a timer associated with the message id. Add it to another map indexed by message id
forward the message
When the ACK is received cancel the timer and remove the timer and message from their respective maps. If the timer fires use the associated id to decide what to do with the timer and message (possibly retransmit and reset the timer).
Netty provides a HashedWheelTimer for efficiently managing lots of timers with a resolution suitable for this kind of activity.
You may also want to consider putting a limit on the number of retries so you can stop and raise an error rather than continually indefinitely.
I need to make a client for an existing protocol. I believe Netty would make that relatively straightforward, but could do with a bit of getting started help.
The protocol uses a connection based approach, but layered on top of UDP, with the actual messages inside a transport envelope, with out-of-order / slow / missing packets, session numbering, and the like all the job of the client.
What would be the best way to create the pipelines & frame decoders etc in netty to achieve this. I've only used netty in a very basic way before - so any advice would be very welcome.
Thanks!
James
It sounds pretty painful. I'm a regular netty user, but I would not implement a protocol like this in Netty (not a ding against netty, but it's implemented elsewhere), at least, the way you have described it. Before you go down this road, I would take a look at JGroups which has implemented a "reliable UDP" stack which features all the transport functionality you outlined.
My first stab at this (if I was on a desert island) would be something like:
Downstream
sendMessage
--> MessageSplitHandler
--> MessageFragmentBufferHandler
RetransmitRequester -->
where:
MessageSplitHandler breaks up the sent message into UDP friendly sized MessageFragments (datagrams) (of which there might be one if the origial message is small enough). For each MessageFragment created from the parent message, assigns each:
the unique id of the parent message.
a sequence number
the total number of fragments created from the original
MessageFragmentBufferHandler stores each MessageFragment until the remote end has confirmed the message has been received (or you elect to timeout the message re-assembly and
ditch unconfirmed messages). Otherwise, keep them around in case the remote requests MessageFragment re-transmitts (probably by parent-message-id and fragment sequence.
Upstream
This will be more or less the reverse the downstream.
MessageFragmentDecoder <--
MessageFragmentBuffer <--
MessageReAssember <--
onMessage
MessageFragmentDecoder: decodes the datagram into a MessageFragment.
MessageFragmentBuffer: stores arrays of MessageFragments until all sequences have been received. If a message is received out of sequence, assume the intermediate was lost and ask the sender to send it again (by unique-id/sequence)
MessageReAssember: When all MessageFragments have been received, this guy re-assembles the original message and passes it to the message receiver.
I think that would be the general idea, but there's probably 200-300 corner cases in there....