[Info-vax] Push Notification Server Software (was: Re: API/RTL providing cURL-esque functionality)

[Stephen Hoffman]

Translating the original Maher into English: Hi folks, I'm looking for 
existing libraries or services available for OpenVMS that can send push 
notifications — that implements server push — for various devices, and 
callable from Java.  Because there are various push notification 
services around — IMAP IDLE is one — I'm particularly interested in 
HTTPS POST push, though capabilities for the the Google GCM and Apple 
APNs push services are also of interest.  {other requirements, 
versions, etc., missing}

Now off to the inevitable wall of text in response...

I've not heard of nor encountered anybody initiating push from OpenVMS, 
but there are probably a few sites using that.  What I've done with 
this stuff focuses on APNs and has largely happened else-platform.

The following posting provides a general overview, though the older 
Google C2DM mechanisms there have been renamed and rebuilt as GCM — the 
fundamental requirements of fewer connections and battery life have not 
changed.  So if you haven't seen this stuff, something like the 
following will provide the flavor of what happens and why...
https://blog.serverdensity.com/android-push-notifications-tutorial/

Related:
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html 

http://googledevelopers.blogspot.com/2013/05/building-efficient-apps-and-extensions.html 

http://stackoverflow.com/questions/11520882/how-to-change-the-c2dm-to-the-gcm
https://developers.google.com/cloud-messaging/

Most developers will prefer to use a central service here, as holding 
open more than one connection to a device incrementally increases the 
drain on the target device battery.   APNs is the one service that I'm 
most familiar with — you send your message to the Apple servers, and 
Apple then performs the notification to the device.   This way, there's 
only one network connection open, and iOS has realigned and rescheduled 
the asynchronous software interrupt activity of those notifications and 
of other software activities to reduce the number of times that the 
processor and the radio have to wake up.

Google now uses a similar approach with GCM.  This parallels APNs.   
(Not only is this more efficient for the target Android devices, Google 
gets to see all of the messages.  Win-win.)

Some of the options around if you're rolling your own — and mixing with 
HTTPS POST requests as well as the central services — include pushd and 
AirNotifier and AeroGear and some others.   Pushd does most or all of 
what's necessary here, but it'll be easier to spool up a pushd server 
on another platform and connect to it from OpenVMS, rather than to get 
the stuff running on OpenVMS.  Same for AirNotifier, etc.

https://github.com/rs/pushd
http://airnotifier.github.io
https://github.com/aerogear/aerogear-unifiedpush-server
https://github.com/countly/countly-server

Amazon and other folks offering cloud services — hosted computing — 
have their own interfaces:
http://docs.aws.amazon.com/sns/latest/dg/SNSMobilePush.html

If Mr. Maher wanted to do just APNs via Java, then JavaPNS and similar 
can be an option:
https://code.google.com/p/javapns/
https://github.com/notnoop/java-apns

Google has some Java GCM services code available, as well:
https://developers.google.com/cloud-messaging/server

To completely roll your own, something akin to HttpURLConnection would 
probably be used.  Some languages have frameworks that can abstract and 
largely avoid the need to muck with sockets directly, and Java is one:
http://stackoverflow.com/questions/1359689/how-to-send-http-request-in-java
http://docs.oracle.com/javase/7/docs/api/java/net/HttpURLConnection.html

If this involves C code, then the cURL folks have a nice list of the 
options, and some examples, and — as has been mentioned up-thread — 
there is a cURL port available for OpenVMS:
http://curl.haxx.se/libcurl/competitors.html
http://curl.haxx.se/libcurl/c/postit2.html

For the client, who knows?   Maybe:
http://jsoup.org

Hosting your own push server on Linux, BSD or OS X will probably be 
easier than porting and re-porting one of the available server options, 
and using one of the commercial notification servers yet easier 
(UrbanAirship is one), but — if you're willing to build your own calls 
— this is entirely feasible from OpenVMS, too.   But it's all code 
you've written or ported, or that somebody else has ported such as 
cURL, as there's nothing useful in the base distro beyond the 
mostly-reliable but crufty C sockets API.
http://urbanairship.com

As for the folks that'll suggest somebody moving into this space and 
helping out VSI, sure.   Have at.   Basic problem being not enough 
folks looking for this stuff on VMS, not enough willing to pay, and 
with the ease of spooling up a Linux instance somewhere running open 
source and just poking that other server with the sort of software 
stick or rock that OpenVMS can still manage to lift up.



On 2016-01-02 04:12:06 +0000, David Froble said:


> Sure looks to me like a message store and forward.  The middleman is a 
> service accepting messages from you.  It then forwards them when the 
> target is available.

It's what's called a pub-sub or publish-subscribe model, from the 
server to the target device.   GCM and APNs provide those servers for 
most of the common devices (Microsoft has their own variant of course, 
but Windows Phone is pretty rare), but it's entirely feasible to 
maintain your own connections, and to then shove a wad of JSON or such 
out to the device via an HTTPS POST request.

> So, when sending to the middleman, you're a client.  The google stuff 
> sure looked a bit like an HTTP POST.  Maybe something similar.

Correct.

> Regardless, at the bottom of every TCP/IP activity is a socket 
> connection.  So, if you can initiate a socket connection, you should be 
> able to work out the details.

Crafted from the finest artisanal binary code, of course.

> Note, one of the links indicated that SSL3 was no longer supported, and 
> TLS would be required.  As of now, HPE does not support TLS V1.2, as 
> far as I know.   Haven't seen the recent release of SSL.

The HPE SSL1 kit is available, and does have TLSv1.2 support.   It's 
based on OpenSSL 1.0-2c.   The SSL1 kit is available via the HPE / HPSC 
patch area, not (yet?) via the OpenVMS SSL web page.  See the start of 
the SSL1 kit thread that's posted here in the comp.os.vms newsgroup — 
Google Groups URL below — for more details on that.   I have the kit 
installed on a target-practice server, and will be taking a more 
detailed look at it.  On the plus side, we don't have to drag 
everything forward at once, as happened between SSL V1.3 and SSL V1.4.  
 On the down-side, the folks that built the kit didn't follow the Rdb 
multiversion approach, which means changing build procedures.

Related:
https://groups.google.com/d/msg/comp.os.vms/ZzXNb2Cbml8/VCw3RAZvBQAJ
OpenSSL 1.0.2e is current, per https://www.openssl.org/source/

> As mentioned before, I got code that requests the socket connection, 
> sends your data, and receives a reply.  Ask if you want it.

Ayup; there's more than a little socket code around, but rather less of 
it that — for OpenVMS — uses HTTPS POST requests and TLS, and the 
TCP/IP Services examples are a bit archaic and tend to be weak or 
missing error handling and related, and the vagaries of device 
connections — unlike the sorts of connections that were expected when 
the TCP/IP Services examples were written — tend to be a little more 
fickle, meaning you're probably in the error paths more than was once 
common.   The other OpenVMS examples tend to be similarly crufty, 
unfortunately.




-- 
Pure Personal Opinion | HoffmanLabs LLC