I am using the node-wot browser library and I would like to connect IoT-devices communicating via MQTT and CoAP to the browser. As the browser/ library is not capable of communicating via MQTT or CoAP, are there any implementations of HTTP-CoAP or HTTP-MQTT proxies available which can process thing descriptions?
The idea would be to have a proxy where I could connect my device to, simply by providing a w3c wot thing description. Ideally the proxy would create another thing description which I could use to connect the browser to the proxy via HTTP.
You can check out the shadow-thing project for an existing implementation but it is rather easy to this yourself with node-wot:
Fetch the TD of the Thing you want to proxy and consume it to create a consumed thing.
Take that TD and put it into the produce() method.
Add handlers for all the affordances
In each handler make the appropriate call to the consumed Thing.
Resolve the messages you get via your exposed Thing so that they are returned to your consumer.
For me the requirements are not that clear.
The open source project Eclispe/Californium comes with coap2http cross proxy functionality (and also http2coap). You may try it demo-apps/cf-proxy2
Related
I am currently trying to create a "TOR version" of a service I created, running with TLS. I want to perform mutual authentication of both parties ; client and server.
I thought about using TLS-PSK over TOR, which would gives me the properties I desire, especially eavesdropping prevention.
I wanted to use the socket library and to double wrap a socket instance using first the ssl library then to do the same thing with TOR, but it looks like there is no library existing allowing me to do the second wrapping.
Do you have any idea about existing libraries allowing me to do something like that ?
I'm working on a PoC of a system where a mobile app client needs to be connected on a server with communications going both ways : either for updating the server or being updated by it. There is no client-to-client communications for the moment.
The client logs in the server via an HTTPS/POST method and gets back a token if the credentials are OK. This token is to be used by any further communication in order to authenticate the user. The reason why I'm using HTTPS for logging in is that there also is a web interface for other purposes.
I could not find a tutorial or documentation that explains how to implement this use case with channels based on websocket transport. All I found so far are either partial and focus on some specific aspects (eg authentication, setting SSL/TLS, etc) and assume the reader already knows the rest or are the over simplified implementations of the chat app. I'm sure I'm not looking at the right place...
My questions are:
What would be the list of callback to implement this use case on
either side
On the server: how does a process send notifications to the
client
NB: I'm using Elixir 1.5.1 and Phoenix 1.3
From the Phoenix guide:
Each Channel will implement one or more clauses of each of these four callback functions — join/3, terminate/2, handle_in/3, and handle_out/3.
The page I linked contains also an MCVE of sockets running on Phoenix. In the bottom there are examples of how the server-client communication is done.
The only thing to apply this to your use-case would be to use one of authentication libraries (e.g. Überauth that comes with great examples) to handle token on each subsequent connection request.
is it technically possible to run multiple websocket servers that listen on the same port and dispatch using the subprotocol name ? E.g. a process that would handle "protocol1" and another that would handle "protocol2". My guess is that it is not, since TCP cannot conditionally accept a connection, so the only way would be some kind of socket ownership transfer.
Actually, it would be possible to achieve by using a Proxy as a load balancer, which isn't something I tried managing before... So I can't post a demo configuration file.
I know Apache will allow you to decide on a proxy path according to the request headers - this means you can check the sub protocol before forwarding the data... But this is mostly a conceptual solution I never tested.
This question is tagged WebSocket++, so I will answer from the context of that library.
Maybe, depending on exactly what you mean. WebSocket++ will let you build one program that can internally handle multiple subprotocols. WebSocket++ has a pre-acceptance hook called the validate handler. In the validate handler you are presented with a list of subprotocols the client has requested and may choose which one you want to accept (or none if your server doesn't support any).
This isn't the same as conditionally accepting the TCP connection itself, but does let you conditionally accept the WebSocket connection. Once accepted your app can inspect the selected subprotocol in the open handler and choose which logic to use to process the connection.
A WebSocket++ based program can juggle multiple connections on multiple subprotocols simultaneously. If you truly want multiple independent processes handling each then the best WebSocket++ will be able to do is act as a proxy for those connections.
Need to be able to continuously receive calls when a Chrome webpage is open. How do I do that even for users who are inside a strict enterprise network?
WebSockets? (but there's the proxy problems that doesn't know what wss:// is)
HTTP? (but will I have to poll?)
Other?
Since you included the "vLine" tag, I'll reply with some information on how our WebRTC platform will behave in an enterprise network. vline.js will use a secure WebSocket by default if the browser supports it and fall back to HTTPS long polling. As described here, the secure WebSocket may work depending on the exact proxy configuration. Feel free to test it out by using GitTogether or creating your own vLine service for testing.
I want to create a messaging service that uses the XMPP protocol. How would I implement the server-side as well as the client side aspects of this service? I know I would need a server (like Jabberd 2) that runs the messaging framework. How hard would this be to set up and get running? Also what would be the best way to hook up a client program into this service? How would i start pushing messages from one client, through the server, to another client?
Server: there are many out there, see http://xmpp.org/software/servers.shtml for a list.
I've used OpenFire in the past, it's fairly straightforward to set up.
You can add a library like xmppframework to your Cocoa project to make it a client, and configure it to talk to your XMPP server.
Each client gets an identifier (called a 'jid') of the form: uniquetext#xmppserver.name, and you send messages from one client to the other by addressing them to the jid of the intended recipient.
If you want to play around with simple examples in a scripting language, you can use something like the examples in the python xmpp library to see how it all works. Use an xmpp client like psi to connect as one jid and use the examples to connect as another jid to send/receive messages through the server.