How should I access a serial port on a client PC from a webpage in a production environment?
Ideally coded in C# and client Blazor, but any suggestions very welcome.
Any example applications on the web?
Web Serial API and Javascript option works in Chrome if you enable the experimental option: "Experimental Web Platform features" : Enables experimental Web Platform features that are in development. – Mac, Windows, Linux, Chrome OS, Android. #enable-experimental-web-platform-features
https://bugs.chromium.org/p/chromium/issues/detail?id=884928
Being experimental precludes use in a production environment till it is formally released (experimental licence must be renewed every 6 weeks, expires in September 2020 and the functionality can be removed by Google at any time.)
So far the only solution I can think of is to create an ASP.NET Core Service application that must be installed on the client and the webpage application must connect to this local API to use the local serial port.
Any technical issues that would prevent this service approach from working? Other approaches I should consider.
The web application will be designed to interface with a central/upper arm blood pressure monitor that outputs large XML (or JSON) results after each measurement. The measurements will be saved into a "cloud" service for research and patient monitoring.
Thank you in advance for suggestions and comments.
I need to implement a social network in the mobile application, in the application I will work with the local database, and then synchronize the data with the Realm Object Server. To handle some user activity, I will use a neural network written in python. How can I implement the work with the data on the server side, which are stored on the Realm Object Server for the needs of the neural network? Is this possible when using the free version (Developer Edition) of the Realm Platform?
That is unfortunately not possible in the Developer Edition. The server side access functionality you need is only available in the Professional and EE versions.
You can read more here: https://realm.io/pricing
Telegram is a cloud based chat service. All of their clients are open source. I was wondering if there's a way to host a 'private' telegram service on my own server.
If not, is there anything out there that can provide all or almost all features that telegram provides?
According to the official telegram FAQ the current answer is no:
Q: Can I run Telegram using my own server?
Our architecture does not support federation yet. Telegram is a unified cloud service, so creating forks where two users might end up on two different Telegram clouds is unacceptable. To enable you to run your own Telegram server while retaining both speed and security is a task in itself. At the moment, we are undecided on whether or not Telegram should go in this direction.
So as long as the server itself is not open-source the entire Telegram eco-system cannot be considered open-source, even though there is an open API and official open-source clients.
There seem to be some unofficial telegram servers, but it's not clear how compatible they are with existing clients.
Some possible telegram alternatives
Matrix is allegedly providing "an open network for secure, decentralized communication" and has both open-source clients (Element being the 'official' one) and an open-source server that can be self-hosted. BUT while it looks good on the surface, there are indications that companies behind it have undisclosed intimate links with governmental actors (similar to Signal).
XMPP/Jabber has been around for a longer time, is an open protocol with multiple server and client implementations, and might be the least tainted by third-party interests. XMPP was the underlying protocol behind the original Google Talk messenger before it was rebranded to Google Hangouts and switched to a proprietary protocol.
Teamspeak a collaborative platform for teams, intended originally for gamers, free client and server.
Mumble a voice oriented solution which allows self-hosted servers.
You could implement a full working Telegram-API, then have hosted clients on your server via this API.
Your users would login on your web, then you sign them in via the hosted clients on your servers.
You are basically performing a proxy service to these users , and you can even integrate other value added features for you users this way.
I was assigned with the re-architecture of a legacy (medical) product which is controlling several external devices. In the current architecture, we have several such stations in each customer's network, where each station is processing its own data, and they all share some of that data via a central server (that talks to the DB and BLOB storage).
I'm planning the new architecture such that it will allow more scenarios, such as monitoring the stations through a web interface, and allowing data processing to be scalable by adding additional servers.
This led me to choose NServicebus as the messaging and communication infrastructure. And I pretty much have a clear view of the new architecture.
However, another factor was recently added to the equation by my manager. He requires that the machine that communicates with the devices (hardware), will not be under the IT policies of the customer. The reason behind this, as I understand, is that we don't want the customer's IT to control OS updates, security, permissions and other settings, because we want full control over that machine in order to work properly with our hardware.
My manager thus added a requirement that this machine will be disconnected from the customer's LAN.
If I still want to deploy NServiceBus on that separated machine (because I want to pub/sub async messages to other machines - some are on the customer's LAN and some aren't), Will it require some special deployment? Will it require an NServiceBus gateway?
EDIT: I removed the other (1st) question, as it wasn't relevant to the scope of StackOverflow.
Regarding question 2, yes it would require the use of a "Gateway", however the current NServiceBus Gateway implementation does not support pub/sub so you would have to look at alternatives.
is there a way for a server to push some data to a client, wirelessly and seamlessly, which may be Windows(Phone), iPhone, Mac, or Android device, without any OS integration?
If so, what's the best design pattern to do this, and what are the best technologies to go about this?
Push technology is simply a methodology of the server initiating the transfer of data, rather than the client asking the server for it.
Apple makes push technology relatively easy to use by providing such functionality built-in on the OS. As well as Android through the Google Cloud Messaging for Android. Windows, however, does not.
Apple push notifications and Google's messaging for Android is seemingly magical and/or functionality that the OS needs to handle; however, this isn't necessarily the case. The advantage of having it "integrated" in the OS, is the same as having a framework handle the functionality for you.
Speaking in technical terms, push technology is a long-lived connection from the client to the server that accepts messages. These messages would be considered pushed messages, since the client did not make an individual request for them.
The main thing to keep in mind when implementing push technology yourself, is that the client is in charge of keeping that long-lived connection alive as much as possible. Because client IP addresses can change between disconnects, servers are not guaranteed that a client's address will be persistent across disconnects. Moreover, clients can be connected from behind a firewall, making it impossible for a server to reach the client.
For comparison, pull technology is the more traditional process of a client connecting to a server and requesting data.
Your best bet for Apple iOS will be using their push notification service.
For Android devices you should use the Google Cloud Messaging for Android. Alternatively, you can create your own background service to handle the messaging; here's a guide.
For Windows (desktop at least), you will have to create your own service to perform such duty. Here's an MSDN guide explaining how to create a Windows Service using Visual Studio (VB and C#). There might be frameworks already built that handle such messaging on Windows, however, I don't know of any.
Use WebSocket (with or without socket.io).
In the future, you could use WebRTC.
With Websockets, the setup is really simple. The client (a user agent, like a browser or a WebView) connects to the Websocket server, over http(s) (less problems with firewalls) and that's it. There's a bidirectional socket with an event-based API.
If by "OS integration" you mean "write special code for each platform" then the answer is no.
As you mentioned, you would like file system access, and background processing. That combination is not available in a cross-platform way at this moment.
If by "OS integration" you meant "without having to wait for apple/google/ms to provide the ability" then the answer is yes/maybe.
All the popular platforms have Push notifications and background processing support, as long as you code it the way each particular platform expects it.
But file system access will be limited to what restrictions the platform places on you. For instance in ios and win8(phone) there is no wy to write or read a file outside of your own apps private file structure. For security reasons, you cannot access the file system of other apps.
UPDATE:
The general pattern here is to release an app for every platform you want to support.
The app will register itself with its respective platform's push notification service.
You will write generic server side code to accept the data you want to push to all your client devices. Then you will invoke the respective push API's for each platform you support, causing the client devices to wake up and trigger the app that you provided to respond.
When the app opens, you get the app to contact your server and download the full data "the push notification being just the wakeup call for your app"
This way you can easily tell how which of your devices have received the data.
Each platform specific app must save the data to its own local storage and provide a way for the data to be shared via the methods supported by its respective platform.
On IOS it can be as simple as supporting the "Open In.." paradigm.
On W8Phone, you'll have to publish the data via one of the available "sharing contracts"
And so forth for every platform you want to support.
This is the general pattern at the moment. There are some caveats. On IOS, the app will nt automatically start when a push notification is received. This means your app will only download the whole of the data when the app is opened by the user.
A mobile app also cannot generally run indefinitely in the background. This means that once the app is started, you have a limited window for push notifications to be automatically processed by your app. After the allowed "background time". The app will close and any push notifications beep on the device, but wont open the app until the user taps on one of the notifications or opens the app directly.
Technically you could use XMPP Libraries, it is meant for implementing chat system (msn, gtalk, facebook chat, etc...) but this could work well as a push message system because it is opensource and well built to handle all the cases you never thought of. Also you could host your own server and send push message that way...
Why not use a webservice? In my previous project I used webservice to deliver data from mysql database. The webservice I used was nusoap. On the client side I used kSoap library for Android. Hope this helps.
if you want to receive and send real time communication between a server and client (irrespective of the device or OS), i would highly recommend you use XMPP technology because it is designed for the sort of things you're asking for.
The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language [XML] that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. The core features of XMPP defined in [XMPP‑CORE] provide the building blocks for many types of near-real-time applications, which can be layered on top of the core by sending application-specific data qualified by particular XML namespaces.
http://xmpp.org/rfcs/rfc6121.html#intro - that is the latest RFC which will give you a good starting point.