I am currently coding an Internet Relay Chat client/server implementation.
I read the RFC 1459 but some points are still unclear to me.
First let's say we have three users A, B and C.
A post a channel message, should I send it back to A, B and C or just B and C ? I mean should the client of A handle their own posting?
And the second point is, I would like to handle the possibility for the user to /join multiple channels.
How then could I handle the fact that my user can only post to one channel at a time? The RFC is unclear about it.
Regards, Swann
In the first sense no. Messages are not broadcast, so the user will not receive their own message back.
When sending a message you provide the destination. Whether that's a user or a channel. So PRIVMSG #channel :hello world will target that message to #channel. Other users in that room will receive the following:
:juco!~juco#hostname.com PRIVMSG #example :Hello world
This is explained in more details in 4.4.1 Private messages.
Related
I know How to send a message for car a to car b or rsu. but I need to send beacons. what is different between sending a message and sending beacons. I cant see any sendBeacon(). How should I send one?
Fundamentally, a beacon is simply a repeated broadcast message that carries some information of general interest in the vicinity of the sender. You can achieve this in Veins by having your application call its sendDown method every once in a while.
You can find some example code that does this in https://github.com/sommer/veins/blob/veins-4.5/src/veins/modules/application/ieee80211p/BaseWaveApplLayer.cc#L242
I use Twilio with my team management system. A text message is automatically sent out for each game. The receiver can then reply with YES or NO. My issue is that when I send two text messages, I have no way to tell if the reply is for the first message I sent, or the second.
Does Twilio have any way to determine which text message it was a response to?
Twilio developer evangelist here.
If you are sending two messages from one Twilio number to the same user number there is nothing within the SMS specification that allows a user to reply to a specific message, so there is nothing you can do with Twilio to detect that.
If you are sending two messages to two different numbers and you get replies from those numbers, you can match against the from number and see what the last message sent from that number was and attach the reply to that.
Alternatively, if you want to get replies from one user to different messages, you could send them from different Twilio numbers. That way you can match the outgoing number to the message and the answer. This is mostly used for phone number masking to enable anonymous communications and there is a good tutorial available on this in the Twilio documentation.
Let me know if that helps at all.
Our scenario is as follows:
We have a marketplace where sellers will receive multiple messages throughout the day from users.
We want to send message notifications etc via sms to sellers
We would like sellers to be able to reply to a sms message notification on their phone. We want what they text to appear as their reply on our site. Is this possible?
Say a seller checks their phone as sees that they have 5 notifications, is there a way they can reply to a specific message rather than the last one sent?
Any help would be much appreciated.
As you describe the use case, it is not possible. As you suspect, there's no way to link one inbound message to a particular outbound message. I'd suggest borrowing an idea from Twitter and including a Base-36 code in the notification. If a reply contains that code, then it's in response to that original message. For example...
Notitification: A seller is interested in your widget. LFLR
Reply: #LFLR Sorry. We are sold out of the widgets.
It will take a slight bit of effort from the sellers. But, then, they are motivated to sell. Using a Base-36 code will keep the number of characters to type under five even for a million plus messages.
Are there any texting services out there (like Twilio) with APIs that allow you to see what message another message is in response to? For example: I want to tell whether message 3 is in response to 1 or 2.
A->B: Do you like ice cream?
A->B: Do you like pizza?
B->A: Yes.
I'm guessing that there's just no threadedness to text messages, and this is impossible. But might as well have a canonical answer out there.... Reasons for this belief:
When you send emails to a phone number at txt.att.net, it uses a different number each time.
The texting services that I've looked at don't offer the feature
The phone UIs I've used all present it as a flat message list rather than a threaded list
Can someone confirm this?
There is no native support for this type of functionality in SMS. Message threading for SMS is inferred on the client side from context. When I send a text to person 1, if I receive a reply from person 1 within a given time-frame, I can assume that it was part of the same "conversation". (I actually implemented something like this for a chat client that I was working on)
I have also seen where the original message is included with the response, and the client can group the messages accordingly (take a look at gmail), but this could be messy if your clients were not the same.
Just a few thoughts.
I'm just starting to research AMQP and I'm wondering if I'd be using it for something it's not designed for. Here's something like what I want to do:
ClientA does goes about it's business
and publishes it's state to some
exchange (correct me if I use the
wrong terms anywhere).
ClientB connects to the same broker
and "says what publishers are
publishing here? I choose you,
clientB. What is going on?".
ClientA says "My foo is bar and my baz
is true"
ClientB says "OK. Set your baz to
false"
edit for a less abstract example"
ClientA talks/listens to a hardware
device, say a video projector. When
ClientB comes online, it wants to find
any projector clients (like ClientA)
that are connected and then to know
the status of the projectors (is the
lamp on?) and also change, if it needs to, the status
(turn the lamp off). So ClientA is
keeping some state (lamp is off) and
can send it out when requested, and
call also respond to commands from the
exchange and convert and pass them to
the projector (turn lamp on).
I'm finding it hard to follow your example, but it sounds like you want these A and B types to have back-and-forth conversations with each other. Is that correct?
AMQP is better suited for asynchronous message passing, and to add the kind of point-to-point style you're describing requires that you set up request and reply queues so that clients can both send and receive messages. It's certainly possible to have clients both publish and consume messages.
This is possible and it would make sense if the different actors in your example, are networked devices because AMQP would provide a loosely coupled way of messaging.
One thing to watch out for is the last abstract line where client B says "OK, set some attribute". That sounds suspiciously like a scenario where subroutine calls return some value and then the next step takes place. AMQP can certainly simulate that kind of RPC, but it works better when processes can send a message and don't have to wait for completing.
If most of your messaging doesn't involve waiting for turnaround replies, then AMQP sounds like a fit for what you are doing. But if most of your needs are RPC, then it may not be the best choice.
AMQP really shines when there are future possibilities, for instance in your scenario, if you needed to add a couple thousand projectors, 10,000 client Bs, and several other device types that also need to exchange status. The loose coupling of AMQP makes it easy to add other applications to the broker, just by declaring new exchanges.