SignalR hosted on IIS. a requirement wants UDP data listener on signalr but being hosted on IIS i couldn't use it as IIS doesn't deals with UDP requests. this made me use redis store for storing UDP data sent by some other server(node/window service). and that data accessed by SignalR hosted on IIS. Redis is faster as said but what transport it use underneath and can it be called as giving clipboard kind of functionality or a sharable memory by applications is the question.
Straight TCP
And the answer is so short I have to type this as well!
Related
I'm a beginner to TCP client-server architecture. I am making a client-server application in C++ I need the server to be able to accept messages from multiple clients at once. I used this IBM example as my starter for the server
server.
The client side is irrelevant but this is my source client.
The problem is with the server side it allows multiple clients to connect but not asynchronously, so the server will connect with the second client after the first one finishes. I want the server to watch for messages from both clients.
I tried to read about select() on the Internet but I couldn't find anything to make the IBM code async. How can I edit the server code to allow the clients to connect and interact at the same time?
Typical system design diagrams for back-end services like Uber involves a proxy and web socket server connection to the client.
I'm curious why only web sockets (and long polling) are considered for these modern web designs. If the demand is for a location update service from a mobile app that constantly pushes location updates to the server, why don't people block out a custom tcp or udp connection between the iOS client and the server for example?
Tcp connection is really what websockets uses under the hood, but with a raw TCP connection, you have way more mature libraries that you can leverage (Netty, Kernel-bypass, FPGA)
Udp seems even better since it's stateless and recoverable during disconnections. If it's a one way stream of location updates, it seems to serve the purpose just fine.
Thoughts?
The main point of using Websockets is that it plays well with existing firewalls, proxies and other limitations. It is not uncommon that devices are used in restricted networks which only allow access to web and mail. It is also nice that it also provides a message semantic (TCP is only a byte stream) and that support for TLS is nicely integrated too. While "raw" TCP might have less overhead, the actual overhead of Websockets is fairly small. And often the overhead of the non-binary payloads (i.e. JSON, XML) is much higher which makes the additional small overhead of Websockets irrelevant.
Does Azure Redis support transport over http. I am aware of the setting that allows me to choose whether to enable SSL or not. But it seems to me the connection to Azure Redis happens over TCP.
"Every Redis Cluster node requires two TCP connections open. The normal Redis TCP port used to serve clients, for example 6379, plus the port obtained by adding 10000 to the data port, so 16379 in the example."
I have also posted this question on the Microsoft forum. It can be found here.
No, Redis (and Azure's as well) does not use HTTP but rather a text-based protocol called RESP. There are 3rd party servers that let you do that, such as Lark, Webdis and tinywebdis.
I am new to Websockets. While reading about websockets, I am not been able to find answers to some of my doubts. I would like if someone clarifies it.
Does websocket only broadcasts the data to all clients connected instead of sending to a particular client? Whatever example (mainly chat apps) I tried they sends data to all the clients. Is it possible to alter this?
How it works on clients located on NAT (behind router).
Since client server connection will always remain open, how will it affect server performance for large number of connections?
Since I want all my clients to get real time updates, it is required to connect all my clients to server, so how should I handele the client connection limit?
NOTE:- My client is not a Web browser but a desktop application.
No, websocket is not only for broadcasting. You send messages to specific clients, when you broadcast you just send the same message to all connected clients, but you can send different messages to different clients, for example a game session.
The clients connect to the server and initialise the connections, so NAT is not a problem.
It's good to use a scalable server, e.g. an event driven server (e.g. Node.js) that doesn't use a seperate thread for each connection, or an erlang server with lightweight processes (a good choice for a game server).
This should not be a problem if you use a good server OS (e.g. Linux), but may be a limitation if your server uses a desktop version of Windows (e.g. may be limited to 200 connections).
I've read about WebSockets but they don't seem to be pure "sockets", because there is an application layer protocol over them. "ws:"
Is there any way of doing a pure socket connection from a web browser, to enliven webpages?
Here are my random stabs in the dark
Applets sockets provided by Java (need java installed)
Flash sockets provided by Flash (need flash installed)
But about HTML5, Why are they called WebSockets if they aren't Sockets?
Is the websocket protocol so simple to implement that it is "almost"-sockets?
I've read about WebSockets but they don't seem to be pure "sockets", because there is an application layer protocol over them.
[Is the] websocket protocol so simple to implement that [it is] "almost"-sockets?
Allowing regular socket connections directly from the browser is never going to happen because it opens up a huge risk. WebSockets is about as close to raw sockets from the browser as you are going to get. The initial WebSockets handshake is similar to an HTTP handshake (allowing web servers to proxy/bridge it) and adds CORS type security. In addition, WebSockets is a message based transport (rather than streaming as raw TCP) and this is done using a two byte header on each message frame.
Even flash is not able to quite make raw TCP connections. Flash sockets also add CORS security, but instead of an in-band handshake, flash socket connections make a connection to port 843 on the target server to request a security policy file.
Is there any way of doing a pure socket connection from a web browser, to enliven webpages?
Yes, you can use my websockify bridge/proxy which allows a WebSockets enabled browser to connect directly to a TCP socket via websockify.
But about HTML5, Why are they called WebSockets if they aren't Sockets?
WebSockets are a transport built on TCP sockets. After the handshake there is very minimal overhead (typically just a two byte header).
I can't improve on Kanaka's answers to your secondary questions, and I know this question is a year old. But for the main question, Is there any way of doing a pure socket connection from a web browser, to enliven webpages? There is a project called the Java / JavaScript Socket Bridge that might be what you (or anyone coming across this page from a Google search) are looking for. The advantage of this method over what others have mentioned is that it does not require either a client-side or a server-side service to be run. So, for instance, if you wanted to implement an IRC client purely in JavaScript but your web host does not allow you sufficient rights to proxy the connection, this Java applet would be the way to go. The only concern is making sure the client has Java installed and allowed.
You can just send data between a client and a server with WebSockets. Simply speaking, the only difference that WebSockets introduces is that the client:
adds some header bytes, like the type of data and the length
adds masks and encodes the data using them
The server also has to add header bytes, but does not need to encode the data.
If you implement the protocol correctly (server side, that is, since the browser already has an implementation), you can use it with ease to send text and binary data. (Although browser support is narrow, especially for the latter.)
The benefit of WebSocket is that it is HTTP based. You can use it also in environments there http proxies are used. Thus Websocket has a higher infrastructure compatibility as plain tcp.
Additionally http/WebSocket is providing you some features which you otherwise have to specify on your own:
Redirect
NAT keepalive
Multiplexing via URI
Framing
If you are asking for some data to be pushed from server it is widely termed as COMET or Reverse Ajax.
Web sockets is still not very popular as there are inherent firewall issues and minimal support yet from popular browsers.
You can take a look at http://www.ape-project.org/ as this is one of the most popular implementations (but native to unix/linux only for now. For windows they suggest using a virtual box or vmware based implementation)