| Remote access to NowSMS server via HTTP and SMPP |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - SMS Issues ⬆ Archive through July 14, 2004 ⬆ |
◄ ► |
| Author | Message | |||
| ashot shahbazian New member Username: Animatele Post Number: 11 Registered: 06-2004 |
Suppose I need to give someone (a customer) with a fixed IP address access via HTTP to my server running NowSMS, which also runs on a computer with a public IP address. He should be able to send messages using his computer. As I understand it, I'd need to do the following: 1. Find out the customer's IP address 2. Set up an account with login/password, Web Logon enabled and message limits 3. Enter the customer's IP address in "restrict to IP addresses" 4. Allow connections to/from the customer's address at port 8800 at my router and firewall. 5. Instruct the customer to open port 8800 at his firewall and properly setup NAT if he's behind a router. 6. Tell him to enter <my ip address>:8800 in his browser to get the NowSMS Web form, then enter his login/password. Would this be all or I'm missing something? How would it be different if I'd like the customer use SMPP via TCP/IP to connect to our server? 1. If I check "enable SMPP Server" can I use the same port 8800 or it's recommended to choose another one? 2. If the customer's using some other SMPP via TCP/IP client software would he need just my IP address/port number and login? 3. Would the customer be able to see incoming messages on my server or some additional steps must be taken for that? Our router is running in a "silent" mode so that no addresses/ports inside are pingable. Would this be a problem? I'm sorry if some of these questions sound stupid - our prospective customer is 11 time zones away and he urgently wants me to set up a test account. The server, meanwhile is in an area with the highest number of unemployed software engineers per capita in the world, hence the security issues. | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 2864 Registered: 10-2002 |
Hi Ashot, Yes, for the HTTP connection, that is sufficient. You might also want to add a restriction for that account (defined under "SMS Users") to the client's IP address. It is a bit redundant, but another check on this can't hurt. For SMPP, the SMPP server does need to be listening on another port. The customer just needs your IP address/port, and login information. SMPP clients often prompt for a lot of extra settings, but the defaults are generally fine. (Recommend that they use TON=1, and international format numbers. That's about the only thing that might trip them up.) For the customer to see incoming messages, you need to specify one or more numbers to route to that account. Under the account definition, you check "Route received messages to user via SMPP". Then for "Recipient address(es) to route to this user", you specify the phone numbers for which the server should route messages to this account. You can have a single phone number specified here, or a comma-delimited list, and you can use wildcard characters "*" or "?" in the phone numbers. To use this feature in NowSMS, you need to define a "Phone Number" under "Properties" for any GSM modem interface in the SMSC list that you want to get routed to that particular customer. When NowSMS receives a message over a GSM modem connection, it records the configured "Phone Number" as the receiver of that message, which will trigger the message to be routed to an SMPP account if there is a match. The queue for an SMPP account is in USERS\accountname\Q, so you can easily test to see if that routing is setup properly without having to involve the customer. -bn | |||
| ashot shahbazian New member Username: Animatele Post Number: 13 Registered: 06-2004 |
Thanks Bryce, got it all! So unlike HTTP queues the SMPP queues for each user are kept separate? Which one gets priority then if I have a few users connected simultaneously via SMPP? What the "preferred connection for" means in Modem properties? Certain users may get priority use of that particular modem? | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 2892 Registered: 10-2002 |
Ashot, Right, there is a queue for each user account. But basically this is for messages that are destined to be delivered to that user account, so it is a little different from the other queue. (The reason for one big queue for the outbound messages is that there could be multiple SMSC connections processing the same queue.) Each SMPP client connection gets its own thread, so multiple client connections are processed simultaneously. (Similar to how multiple SMSC connections are processed simultaneously for the outbound queue. Only the SMPP client connections are processing a separate queue.) The "Preferred connection for" entry has to do with routing. Basically if you want to route different countries or phone number prefixes to different operators. When NowSMS routes a message, it first looks to see if a sender address has been specified for the message submission (normally there is not a sender address specified, unless you submitted the message via HTTP and specified a "Sender=" parameter, or a forced sender address is associated with a particular "SMS Users" account). If a sender address was specified, then NowSMS checks to see if the sender address matches the "Default Sender Address" that is configured for any of the SMSC links (or the "Phone Number" associated with a GSM modem). If NowSMS finds a match, then it will route the message only via an SMSC connection with a matching sender address. If NowSMS did not find a match on the sender address, then it evaluates the recipient address, and it will look to see if it finds a match in the "Preferred SMSC Connection for" recipient address masks associated with any of the SMSC connections. (These recipient address masks can be wildcards such as "+44*" to match any phone number that starts with "+44".) If NowSMS finds a match, then it looks for the longest mask that provides a match, and routes the message via the connection with the longest matching mask. (For example, if you were sending to +441624999999, and you had one connection with a mask of "+44*", and another with "+441624*", then the connection with the mask of "+441624*" would be used as it is a longer match than "+44*".) If there is no match on the recipient address mask, then the message will be routed via any connection that has "Support any outbound message traffic" checked. -bn | |||
| ashot shahbazian New member Username: Animatele Post Number: 15 Registered: 06-2004 |
Okay, thanks! There's still a question: Suppose I have a gateway with 10 modems, which is fully backed up with a large queue to France. At the same time, I have prospective clients from the UK and Spain with test logins via HTTP, and those clients want to test connectivity to their countries. How could I configure the server so that each time these clients submit a message it gets processed ahead of the messages queued for France, without stopping the server and removing tha large queue? Suppose I can't designate one out of these 10 modems entirely to these testing customers - all 10 modems should be sending to France. Once one of these clients decides to test then one of the modems (or a few modems) would immediately process the test messages, then continue with the French queue. Is this possible? | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 2910 Registered: 10-2002 |
Ashot, Hmm...(thinking)... We could use some type of message priority support. The immediate answer is that you'd have to dedicate a modem for such a purpose. However, I do want to give this some more thought. I would like to see some sort of priority system to be implemented. However, I don't like the idea of a static priority system. It would be nice to have something that could adjust things a little more dynamically. But that requires quite a bit of thought. -bn | |||
| ashot shahbazian New member Username: Animatele Post Number: 17 Registered: 06-2004 |
Bryce It may have worked if the program could do just the oposite of "Preferred SMSC Connection for," i.e, if I could designate one modem as the "Unpreferred Connection" for country code +33, or "Preferred Connection to All Countries Except those with codes +33 etc.". Would this be possible? | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 2981 Registered: 10-2002 |
Ashot, Sorry for the delay responding back to this. Hmm... That would seem to make sense. You could accomplish this by defining "+33*" as preferred connection in the other modems ... yet leave "Support any outbound message traffic" checked. What this means is that "+33*" messages would only be routed via one of the connections that has the preferred definition in place. (Basically, if there is any preferred match, then the message can only be routed by a connection with a preferred match ... the "Support any" no longer applies to that message.) Does that work for you? I realise that it might be a better option to have an exclude list. -bn | |||
| ashot shahbazian New member Username: Animatele Post Number: 18 Registered: 06-2004 |
Bryce I'm afraid it won't, if, as you say, the messages to France would be submitted via those connections only where +33* is checked. That'll be the same as leaving one channel out of 10 as a "priority" channel for testing customers only. In fact the task seems far more complex than that. I've been receiving numerous requests from our customers asking to prioritise traffic. Everyone has a different sending schedule and has messages which could be flagged as "Bulk", "Bulk restricted hours" and "Priority", or real-time. Suppose we have a gateway with 100 modems, each having a throughput of 600 msgs/hour and have 10 customers, each with his/her schedule and a set of requirements for priority. The task is to distribute the load between modems in an as much even fashion as possible and being able to tell the custmomer right up front: "No, you cannot send 200,000 messages between 8 and 10 in the morning. Your today's options are: between 8 and 12 at 2.0 cents per messaqge, between 8 and 18 at 1.8 cents and between 18 and 22 at 1.6 cents (this is off-peak, supposedly)" I can see at least the following that needs to be implemented to make anything like this possible: 1) ability to evenly (and unevenly) share the modem pool between several customers 2) giving higher-paying customers incremental increases in throughput, - above should be true for both "bulk" and "priority" traffic 3) Fixing the cusomers' orders on first come - first serve basis, i.e., each customer would be seeing what exactly he/she is able to book on a certain day, depending on what other customers have already placed for the same period. This may be somewhat similar to an airline ticket reservation system. Spare throughput is the available seats, cheapest bulk traffic is 21 days in-advance reservation, next day or the same day bulk orders are full price economy, priority traffic are the business and the first-class seats. Do you think this would be way too difficult? Actually, I came up with a better and broader idea - would share it over email if you like. Regards, Ashot | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 3012 Registered: 10-2002 |
Ashot, I'm not sure the "unpreferred connection" approach would work. I think we're looking at it as a routing inclusion/exclusion attribute, whereas you'd like to see it related to some priority processing. Ideally, I'd like to see some priority support in our message handling, where the submitting user has some control over priority. But I see that as a little more of a longer term issue for us. A shorter term issue is to have a solution to help stablise traffic jams. What I mean is this ... if you have one customer who has initiated a bulk campaign, you do not want this to block/significantly delay message delivery for other customers. What I'd like to see is a dynamic priority adjustment that lowered the priority of the bulk messages automatically. So if one customer submits a large batch of messages, we limit how many messages we process from that customer before checking to see if there are any messages from other customers to process. I think I've got a pretty good idea of how this would work. I've been going over a basic design of this with one of my colleagues, and I think we just need to adjust to separate outbound message queues per user account in order to facilitate this. Now it's just a matter of finding the time on the development schedule. -bn | |||
| ashot shahbazian New member Username: Animatele Post Number: 19 Registered: 06-2004 |
Bryce Being able to exclude certain network codes for submission through GSM modems is a necessity. It is very common that retail customers have the widest conectivity options abailable through their handsets (GSM modems,) i.e., there would be an ability to text to a certain country's 5 out of a total of 6 ops. Defining "excluded" carriers' prefixes would be relatively easy, while entering hundreds of "preferred" codes - a few per carrier, and that's for each of the SIM-cards used, is an enormous task. Dynamic priority: here's some thoughts: 1. The SMS providers' systems are geared to send messages one by one in sequence - that's been my experience. The gateway would never know up-front what's coming - an avalanche, a 100-message batch or just a few messages. One of the solutions would be setting a default initial (sending, not submission) rate for everyone, and then increasing it by pre-determined steps every couple of seconds, while continuously monitoring the overall sending load. Once the overall load reaches, for example, 90%, it stops there to leave some room for new submissions and "priority" traffic. Once there's a new submission the system should start with it slowly, and realising there's a growing backlog queue for it, should gradually and proportionally decrease other users' throughput while increasing the new user's throughput at the same time, to make it "fair" for everyone. That's the case where all users have the same priority. For users wishing (and paying for) higher throughput there should be a possibility of adjustments on their accounts to push their traffic faster in relation to that of the other users. This is all irrelevant of the "advance reservation" system I spoke of in my previous post. With that in place, it'll obviously get more complicated. 2. The above method (and any dynamic load management) would become a disaster if there's no facility to manage the schedules. Texting late at night is a no-no: if the customer's queue hasn't cleared by the cutoff time because of the overall increase of the sending load, it should pause, then resume in the morning, according to that customer's schedule. 3. Having the load monitoring capability could become a first step to enabling the gateways to be networked. Suppose you have a few gateways each connected via SMPP or HTTP with its peers. Every one of the gateways sends a "token" once a second to other guys, for example 230/10000,300;5670/10000,5 - "my current average load within the past 5 minutes was 230 per minute out of 10,000 possible, and it was 5,670 in the past 5 seconds." If the software allows for re-distributing the load between several gateways with some intelligence and based upon the sets of preferences for each of the users, then the problem with jams may be solved quite efficiently. After all, no matter what kind of load management is in place on a single machine, no gateway has unlimited capacity. Those utilising GSM modems are obviously the slowest and most vulnerable. Regards, Ashot | |||
