I have several servers handling the same requests and several clients sending requests. The servers are routers to keep/track the identity of the clients and the clients are dealers which round robin servers. Does this dealer/router pair without a broker make sense? It works and fits my need but I don't see this pattern on the official guides.
If you are trying to balance your request loads between servers at the client, yes you are right. This pattern is named client-side-load-balancing. You can read about that here
But I'm not sure about your implementation.
You can see more in google SRE book.
Related
I use SMPP routes towards providers, which have others providers in order to send SMS until the local operator.
My question is... How can I know how many provider hops there are in each SMS via SMPP?
I mean, since the SMS is sent towards the next provider until the SMS is delivered in the handset, does exist any way to know how many hops there are?
Could I add any information in the SMS in order to get this information?
I would like to get this information in order to know if the route is good or not.
Thank you.
With standard SMPP it is not possible to know how many hops (i.e. SMS gateways and SMSCs) there are between your application and the handset.
Monitoring the latency between submission by your application and delivery to the handset can provide a hint at there being multiple hops. This approach isn't reliable as high latency could simply be a slow single hop rather than multiple hops.
Asking your immediate provider how they route your messages can provide some insight. If they send directly to an SMSC belonging to handset's mobile network operator then you know that it should only be a hop from you to the provider and then another from them to the MNO. Probes, or your own testing, can be used to confirm if your message is being routed directly to the handset's MNO. In such cases you will see an SMSC address (SMSC GT) in the receive SMS that belongs to the handset's MNO.
It is not part of the SMPP protocol to know the hops to the final SMSC that delivers your SMS to the destination mobile. Number of hops does necessarily account for delays in SMS delivery.
If you will like to know if a certain route is good or not you could use other metrics like how many successful delivery reports have been received for SMSes sent via that route to build a table of good routes and bad routes.
Definetly not part of the SMPP protocol. For sure your sms won't be delivered via SMPP only, but also via SS7. The performance could depend on so many factors ... I think the best way to evaluate a 'route' is ( as other have said) to build some metrics/kpi's yourself and analyze them.
I have a concox GT06 device from which I want to send tracking data to my AWS Server.
The coding protocol manual that comes with it only explains the data structure and protocol.
How does my server receive the GPS data collected by my tracker?
Verify if your server allows you to open sockets, which most low cost solutions do NOT allow for security reasons (i recommend using an Amazon EC2 virtual machine as your platform).
Choose a port on which your application will listen to incoming data, verify if it is open (if not open it) and code your application (i use C++) to listen to that port.
Compile and run your application on the server (and make sure that it stays alive).
Configure your tracker (usually by sending an sms to it) to send data to your server's IP and to the port which your application is listening to.
If you are, as i suspect you are, just beginning, consider that you will invest 2 to 3 weeks to develop this solution from scratch. You might also consider looking for a predeveloped tracking platform, which may or may not be acceptable in terms of data security.
You can find examples and tutorials online. I am usually very open with my coding and would gladly send a copy of the socket server, but, in this case, for security reasons, i cannot do so.
Instead of direct parsing of TCP or UDP packets you may use simplified solution putting in-between middleware backends specialized in data parsing e.g. flespi.
In such approach you may use HTTP REST API to fetch each new portion of data from trackers sent to you dedicated IP:port (called channel) or even send standardized commands with HTTP REST to connected devices.
At the same time it is possible to open MQTT connection using standard libraries and receive converted into JSON messages from devices as MQTT in real time, which is even better then REST due to almost zero latency.
If you are using python you may take a look at open-source flespi_receiver library. In this approach with 10 lines of code you may have on your EC2 whole parsed into JSON messages from Concox GT06.
I've been reviewing Websockets messaging protocols. Looking at WAMP, it has the basic features I want. But in reading the docs, it appears that it requires a messages to route through the broker. Is this correct?
I am looking for real time messaging. While the broker role may be useful as a means of bringing together the publishers and subscribers, I would want the broker to only negotiate the connection, then hand-off sockets/IPs to the parties - allowing direct routing between the involved parties without requiring the broker to manage all the real time messaging. Can WAMP do this?
Two WebSocket clients (e.g. browsers) cannot talk directly to each other. So there will be an intermediary involved in any case.
WAMP is for real-time messaging. To be precise, WebSocket is for soft real-time. There are no hard real-time guarantees in any TCP based protocol running over networks.
Regarding publish & subscribe: a broker is always required, since it is exactly this part which decouples publishers and subscribers. If publisher would be directly connected to subscribers (not possible with 2 WebSocket client anyway, but ..), then you would introduce coupling. But decoupling a main point of doing PubSub anyway.
What exactly is your concern with having a broker (PubSub) or a dealer (RPC) being involved? Latency?
So i have been making a live chat room with my websockets app, using socket.io.
But i also have a secondary feature that requires real time that is unrelated to my live chat feature. So I wanted to know should i run a separate app on a different port ?
Does this provide any technical benefit on performance and scalability ? Or should a website use one app which handles all web socket data.
I'm no expert on servers so i was wondering if there is a correct approach for this on a technical aspect.
Please note: I'm not looking for opinions only factual truths of pros and cons of separating over centralising.
Assuming there is any pros and cons at all. The lack of documentation on alot of websocket frameworks don't really go into much detail on this particular aspect.
WebSocket Apps and Ports
Q: So I wanted to know should i run a separate app on a different port ?
The short answer is yes because unrelated services may expect different growth patterns, so you want to separate the functionality as much as you can so you can deploy one or more services on the same box on different ports.
The longer answer is that you should do this to separate things internally, but it sure would be great if you could let your clients access all your services over ports 80 or 443 - with WebSockets you can use the WebSocket URL to distinguish services and share the same port.
To achieve this, you can introduce a WebSocket gateway application that supports port-sharing. Then your clients can hit port 80 for every WebSocket service, but you utilize different ports for your separate apps.
If your WebSocket gateway application supports port-sharing for WebSockets it means your server accept on the same port with different paths... e.g.
ws://example.com:80/chat_service
ws://example.com:80/unrelated_service
In general to get traffic over the Internet at large it's better to use ports 80 and 443, port-shared if you can, to pierce through any number of intermediary proxies/firewalls along the way.
Q: Does this provide any technical benefit on performance and scalability ? Or should a website use one app which handles all web socket data?
Just like an application server, there is no reason why one WebSocket server should not serve multiple different web applications. If you expect the applications will experience different growth rates, you should separate them into separate web apps, sharing libraries.
For performance, if your applications push a larger amount of data over the WebSocket to the clients, you might want to consider the total network interface traffic of all services to make sure you are not maxing out the bandwidth of the network card. This is independent of your separate port question.
For scalability, if the functionality is unrelated it will be more scalable to keep things separate and share libraries if necessary. This is because you may experience different growth levels for the unrelated services.
Summary
I'd suggest the combination of keeping things simple for clients and scalable for the servers is as the following:
Use a WebSocket gateway that can port-share. All clients can use 80 or 443 with separate paths.
Configure the WebSocket gateway to proxy through to separate apps on separate ports to allow for the servers to scale independently.
+----------+
+------| App:Chat |
+--------+ +---------+ | +----------+
| Client |-----internet------| gateway |------+ (port 8081)
+--------+ +---------+ |
(port80) | +----------+
+------| App:App2 |
+----------+
(port 8082)
Gateway solutions like the Kaazing WebSocket gateway offer this type of functionality and are free for development use up to 50 connections at a time.
(Disclaimer: I used to work for Kaazing as a server engineer).
I don't have a definitive answer for you but two things that may be helpful
1) There is a great book from O'Reilly on browser networking which you can actually read online for free to learn how the series of tubes that we know as the internet actually works. Here is the chapter on WebSockets (which is in the latter portion of the book) http://chimera.labs.oreilly.com/books/1230000000545/ch17.html. I just skimmed this and found a paragraph on multiplexing which seems relevant to your research.
2) One reason that springs to mind for why you may want to have the separate connections is that they act as FIFO queues so if one your 2nd usecase involves large payloads, the chat session would essentially hang while that payload transfers. Surely there are other reasons to go one way or the other though and hopefully someone else can give you a more complete answer.
I hope to create a web server that can give some extra facilities for SMS Service Providers. Can I send SMS through internet? If its possible then, Are there any libraries for Send and Receive SMS over the internet?
There are many different options to send SMS over Internet, but most popular are the following:
Connecting to SMSC of mobile carriers directly (usually via SMPP protocol).
Connecting through some SMS aggregation service like Clickatell mentioned in previous answers.
Choice between these options depends mostly on non-technical issues:
Required coverage (mobile carrier will provide only messaging inside it's network).
Premium Rate billing possibility (this requires closer work with carrier).
Well, price too... :-)
Technically most popular options are:
Specialized protocols like SMPP (Short Message Peer to Peer).
HTTP based protocols provided by SMS aggregators.
If you need unified solution, I recommend to use Kannel open source SMS gateway that support many popular transports (SMPP, CIMD, UCP, HTTP, etc).
You've got www.Nexmo.com www.tropo.com www.twilio.com www.smsified.com ... and so on...
You can use http://www.clickatell.com/ which gives you a few options such as sending SMS one by one, or by using bulk files such as XML.
I found the clickatell API to be really usefull and easy, I managed to add SMS capability to an existing website in a few hours by creating a simple class to wrap up all the methods.
One thing to remember though this is not going to be free for you, there will be costs involved depending on where you send the text to, and where you are based.
You can send SMS programmatically through TheTexting API, They provide cheap rates and their service is really good.
Full disclosure: I work for company that makes this product.