I'm confused by the GAE documentations. It says App Engine supports sockets without requiring you to import any special App Engine libraries or add any special App Engine code. but it seems misleading as just above it says App Engine supports outbound sockets through the appengine/socket package.
I would like to connect to an IMAP server using the standard net package. Is that possible or I'm stuck with the GAE sockets API?
https://cloud.google.com/appengine/docs/go/sockets/
It is not possible to open an outbound socket without going through the appengine/socket api. This is because it works through RPC and an appengine.Context is needed to do that. You can still use the IMAP library you linked, though, as it provides a function to create a client with a given net.Conn. You can get a net.Conn from appengine/socket and pass it to NewClient to do your business. The reason it works on python and java is because they both use thread local memory to manage request state implicitly, whereas the go runtime does not.
Nothing stops you from connecting to an Imap server, since you will initiate an outbound connection. For java, the standard java mail packages work out of the box.
Only for paid apps though, i.e. you need to have billing enabled.
Related
For one of my application, I have implemented Web socket using socket.io and hosted in IIS. Currently socket connection helping to provide two way connection between client (React) and server (node.js).
As I mentioned, I have hosted my application in IIS. I have few doubts regarding Turn Windows features on or off -> Internet Information services -> World wide Web Services -> Application Development Features -> WebSocket Protocol. I have tested my application without enabling this feature, its working fine, but I would like to confirm below stuffs.
WebSocket Protocol
Do I really need to enable WebSocket protocol feature to make websocket work in my application? If so, how now it is working fine without enabling (I haven't do performance and stress testing, I may face issue on this).
What if I not enabling this feature? in short what is the actual use of this feature?
It would be helpful if anyone answer the above questions. Thanks in advance.
WebSocket as part of the HTTP stack requires a bunch of things to be ready on Windows (across multiple components), so hope this answer helps a little.
HTTP.sys, a driver deep down in Windows OS, is upgraded to support the necessary packet communication required by the protocol.
The IIS WebSocket module, an IIS extension which many other Microsoft frameworks (like SignalR) depend on.
So WebSocket support is by default on in HTTP.sys, and you don't need the IIS module if your framework (socket.io) has no dependency there.
Note that the "Summary" section provides several useful links,
https://learn.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-websocket-protocol-support#summary
and the same article also reveals that IIS WebSocket module has
conflicts with socket.io.
I have the task of implementing iot device management using Eclipse Leshan. I have difficulty understanding how Eclipse Leshan works in connecting IOT sensors with servers and cloud. Is it true if I declare that Eclipse Leshan does not require a gateway like Eclipse Kura to connect into server and cloud?
Does anyone know where the complete documentation about Eclipse Leshan is? it would be very helpful if there were examples of programs in implementing the eclipse leshan.
Thank you
Eclipse Leshan is a library for implementing applications that use the LWM2M protocol to manage devices. As such, your application can use Leshan's Java API in order to interact with devices that also support LWM2M.
LWM2M does not per se mandate a transport protocol. However, the spec is written assuming that CoAP over UDP is used for that purpose. In fact, the LW in LWM2M stands for Lightweight and as such, using CoAP as the transport protocol makes a lot of sense for managing constrained devices.
Eclipse Leshan itself does not connect to a server or cloud but instead is usually part of an application that is hosted on a server (on the cloud). However, you need to implement that application yourself because Leshan, as indicated above, is just a library. The devices then interact with your LWM2M enabled application. Because CoAP/UDP uses standard IP, this interaction can occur over public internet infrastructure if desirable in your use case, i.e. no gateway is necessarily needed. You can, however, also connect your devices to a local gateway, e.g. Kura, and then connect the gateway to your LWM2M server in the cloud instead. It really depends on your use case and the capabilities of the devices.
I want to be able to execute local shell commands in a web application.
Chrome Native messaging api seems to be good for that, but as it needs also a service in background, I do not see a real difference with a little http server.
Is there a real structural difference between them? As I see there is somewhere a socket used as an interface.
Is there any other solutions for that?
Chrome Native messaging does not work by calling a running daemon. Instead, it spawns a new process each time sendMessage or connect is called.
While you can keep the process you opened with connect running, if you want to do one-shot commands the sendMessage approach is good.
Do note that you will still need a Chrome App or Extension installed to be able to do it, as well as a (separately installed) Native Host module.
I need to show to a user an interface of some application running on a server using a browser. It should be like RDP-client for a single application on a server.
Are there any solutions or services that can implement following functionality? Maybe Citrix?
Thanks in advance!
This looks like what you're looking for:
http://freerdp.net/
About FreeRDP-WebConnect
FreeRDP-WebConnect is an open source gateway for accessing RDP
sessions using any HTML5 compliant browser. In particular it relies on
the Canvas and the WebSockets feature. FreeRDP-WebConnect is a
subproject of the FreeRDP project.
On the server side, a standalone daemon - written in C++ - provides a
Web page via HTTPS (or HTTP, if configured) and uses FreeRDP libs to
connect as a client to any RDP session. The server side WebSockets
implementation handles current RFC6455 only, so browsers that
implement the older drafts do not work. With RFC6455 being raised to
the "Proposed Standard" level, this should change now really soon.
I would create an account on the server for the user, and only give it access to the one application it needs access to.
You can use Cameyo. To start, create yourself a free account, and click on "Add App". If your installer supports unattended installation, you simply need to submit it. Otherwise, you can build a Cameyo package locally and send it in. It will then be playable as HTML5.
You don't indicate what server you are running on.
As an alternative to FreeRDP-Webconnect cited above, also open source and also using FreeRDP as rdp client through an HTTP gateway, there is Myrtille.
FreeRDP-WebConnect embeds a standalone daemon written in C++ to provide a web page via HTTP(S), and so will also work on Linux servers, while Myrtille have a IIS/.NET (C#) implementation and an MSI installer, thus is more intended for Windows Servers.
Hosting an application on a web application server e.g. JBoss automatically brings in lots of app server specific functionalities with it e.g. security, clustering & load balancing etc. I have a situation where I have to develop a server app with which, legacy apps can talk to over TCP/IP socket as well as be highly available. Initially, I had though of using JBoss app server to leverage its clustering support for HA. However, I am not sure whether it would be possible to connect to a JBoss web app using pure TCP/IP sockets from both java and non-java apps.
What is the best way to achieve this without using web service or Http approach?
UPDATE: I am specially interested to know how legacy apps will connect to the hosted web app through TCP/IP socket.
A really simple solution to bridge the two worlds would be to add a simple Java server which maps the old TCP/IP requests to HTTP requests. This is probably a pretty braindead task, so this "server" will be simple to write and maintain. Also, this server won't need as much power since it just accepts and forwards connections (no business logic or DB code).
On the JBoss server, you develop like you normally would. The legacy apps connect to the little bridge server which passes the requests on to JBoss and translate the result back.
This ensures that you're building for the future: When new apps are developed, they can connect directly to JBoss and use all the great HTTP features.
There's no reason why you can't open up a normal socket in (say) a servlet application hosted in JBoss.
You can then get a byte stream from this. The headache is then to decide on a platform-independent representation of your messages, such that your client end can format and send such that the JBoss-hosted end can read. But it's all perfectly feasible.
I would implement a very simple http (1.0) client.