SignalR for Xamarin doesn't have way to work through Websockets.
I have a web service with messaging by SygnalR by websockets.
Can i receive message in Xamarin without implementing SignalR to Xamarin?
Is it important to have SignalR on Xamarin client side?
If you have implemented a SignalR hub in your sever, you can use SignalR Client nuget in Xamarin. The transport will be SSE (Server Sent Events) by default, but it works pretty well.
Implementing a websocket in the client just to connect to a SignalR server makes no sense at all, unless you really need to use WebSockets instead of SSE.
SignalR uses transports to connect to the server. The portable version of SignalR client does not support the webSockets transport since there is no portable version of WebSocket client available. This is fine since there are two more transports - longPolling and serverSentEvents that can be used to talk to the server.
You can't connect to the SignalR 2.x server with bare webSockets. There is a protocol that needs to be followed and if a client does not follow this protocol its requests will be rejected.
If you absolutely need to use websockets you can implement your own websockets transport by implementing the IClientTransport interface and pass it to the Start method. This is how the webSockets transport is supported on UWP. Here is all the code I needed to write.
Related
wss://www.mysite.ca/socket.io/?EIO=3&transport=websocket
This is how chrome webdevoloper tools shows the request url of a socket io.
I am trying to understand more about EIO=3&transport=websocket .
I have to invoke the url from an API tool
These are query parameters that the socket.io client sends to the socket.io server as part of the initial connection request.
EIO=3, I believe, is the version number of the engine.io sub-system in socket.io. If the server is not compatible with this version number, it will likely fail the attempt to connect.
transport=websocket says that socket.io wants to use the websocket protocol as the eventual transport. socket.io has several different transports it supports including web polling and a flash-based protocol.
To connect to socket.io server, you will need a full-fledged socket.io client. You can't make a socket.io connection by just sending a URL from a tool to the server. There's a lot more involved than that in establishing a working socket.io connection.
Assuming both browser & Server supports a web-socket connection.
If I've got 2 hubs on my SignalR server. and my SignalR client connects to both. does that mean that my signalR client will open up 2 separate web-socket connections to the server?
In SignalR v2+, hubs will share the same connection. I've had systems with connections to 4+ hubs without performance issue.
Question is a bit of a duplicate of: Multiple signalR connections/hubs on your website
I'm experimenting with mqttjs and websockets and I wish to be able to send messages from a webpage using websockets without a bridge to an MQTT broker that is run by mqttjs. I can't find any information if this is available or even possible.
I've looked at mosquitto and they have "experimental" websocket support and I would love to find a Node.JS MQTT broker which could offer the same.
Thus far I got the communication working with pywebsocket and Socket.IO. I would really appreciate pointers in any direction if it is possible to use websockets to mqtt without bridging.
Thanks.
Is old question but is good to share my findings.
You can use the mosca broker that is written in node.js and is using mqtt.js
The mosca is supporting classic mqtt connection and mqtt over WS :
MQTT-over-Websockets
Mosca can operate in two modes: Standalone and as a node.js module.
In general mosca can support many types of brokers:
Mosca-advanced-usage
HiveMQ supports native websockets, which means you can use any Javascript MQTT library (like Eclipse Paho.js with websockets. It's perfectly possible to connect some clients vie websockets and other clients via standard TCP connection. The websocket support is stable and used in production.
The only drawback for you could be that HiveMQ is not written in Node.JS.
Disclosure: I am one of the developers of HiveMQ.
I want to develop a web application in which client calls a service on server to do some action which involves some processing. Server will do all the necessary processing and when the updated data is ready it will push that data to client. Currently I am considering two approaches: -
1. Using ASP.NET WEB API with SignalR
2. Using WebSockets with WCF in .NET 4.5.
My server will be on Windows Server 2012 but majority of my client will be IE 9 which I think do not support WebSockets.
As written in the SignalR documentation that it automatically falls to Long Polling if WebSockets support is not present without changing the application code. Whether this is also supported by WebSockets in .NET 4.5 or I have to do it manually. Means whether I have to implement both the Pull method and push method on the server.
Please guide me, which approach I will have follow.
In later use case I want to build this web application using PhoneGAP to create mobile app for iOS, Android & Windows Phone.
WebSockets does not fall back to longpolling (that doesn't really make sense). SignalR is a higher level abstraction over http transports and that's why it does the fallback and other things (like provide a nice programming model over a connection).
If you choose to use websockets on ASP.NET (not sure about WCF) you'll be programming against raw sockets (this means reading/writing array segments etc) and doing a good job at that is hard. SignalR does this for you and will fallback to several other transports (forever frame, server sent events, longpolling) if websockets isn't available on client or server.
Regarding clients, if you choose to use SignalR you'll need to use a SignalR client. We only have support for javascript and .NET (silverlight, windows phone 8, winrt, .NET 4 and .NET 4.5). Some people have written clients for other platforms including iOS and Android but we don't maintain them so I can't speak to how up to date they are.
I'd recommend you use SignalR so you can focus on your application logic instead of messing with the low level programming model of websockets.
You could start with the ASP.NET Tutorial http://www.asp.net/signalr/overview/getting-started/tutorial-getting-started-with-signalr
After this tutorials you know all the basic thing you need to know about SignalR
I can confirm that the fallback works automatically. If websockets transport can't be used, ServersentEvents transport would be used.. and so on.. the last transport protocol is longpolling.
Our SignalR server is a .NET 4.5 framework app, hosted in an ASP.NET MVC App using 4.5 dlls on a windows 2012 server. The application pool is ASP.NET 4.0.
A .NET 4.5 client on a Windows 8 or a windows 2012 server seems to use websockets.
The same .NET client on a Windows 7 machine (even with framework 4.5 installed) falls back to serversent events transport automatically.
With Signalr javascript clients on a browser, a similar thing happens:
Chrome/Safari/other browsers that support websockets seem to use websockets.
IE/other browsers that don't support websockets, but are relatively late versions seem to use serversentevents.
From experience, serversentevents is not very bad, therefore don't be put off if websockets isn't being used and certainly don't use that as the sole factor against using signalR as the benefits are many.
Hope this helps.
sorry for my dumb question, now that i got that i must use Javascript to use Websocket, this is client-side, but what about Serverside, why do i find people talking about RabbitMQ, Stomp, SocketIO, Tornadio
in the Tornado example, no one of them exists, so i said that Tornado is enough, but i found that people use them even with Tornado, here and here.
So what do i use? and for what?
Actually Tornado is a web-server and it supports web-sockets. Other things in your post are not webservers.
RabbitMQ is a message queue service, it's used to communicate between different services on the server
STOMP is a protocol to work with message queues.
Socket.IO is a framework that allows you to use websockets easily. But it requires Node.JS server on the server side. Socket.IO provides you some fallbacks if browser do not support WS protocol. Tornadio is a port of Socket.IO to Tornado. So you can use the same client framework (in web-browser) but on server-side you use Tornado instead of NodeJS.
So Tornado is enough for websockets. But if you'd like to create more complex apps you'll have to use other tools for other tasks. From your list - you can use Tornadio to deal with legacy browsers and RabbitMQ for interprocess communication on your server