I need to set up a (bidirectional) communication channel between a C# application and a Max for Live Patch (Max 6).
One can run JavaScript inside a Max patch (pretty lightweight) and I thought about using named pipes inside JS for sending data out to a C# server. However I have no clue how to set them up in the Max environment because things like ActiveXObject cannot be used.
Is this possible to achieve or do I have to write a Max Extension in C as a proxy?
(Or should I rather go with a network connection?)
Any hints welcome!
Regards,
Moritz
I admit that I don't have much experience with named pipes, but regardless I would recommend setting up a network connection.
Most Max users that need to communicate with other applications use the native UDP objects udpsend and udpreceive along with the OSC protocol developed at CNMAT. I prefer TCP / Json myself, and have been frustrated by the lack of native TCP support in Max. Depending upon the needs of your application, it could be very important to know when clients disconnect, to ensure that packets arrive in the proper order, etc--features UDP does not provide.
For this reason, I have started developing a native TCP client for Max using Unix sockets. Since you are using Windows, this won't work for you out of the box, but the basic building blocks could still be useful. If you want to add winsock support, that could be a great benefit to the Max community.
Related
I'm in the middle of a very large project to migrate my application from Java to JavaScript, and am trying to decide what the messaging protocol should be for client/server. Some notes on what I'm looking for:
There is a very large amount of data streamed from the server to client, with infrequent small requests made from the client to server (responses may be large). Network performance is a very big concern.
We are going to deploy the new JS-based client primarily in an Electron container, but with support for "modern" browsers in the future (no ETA for that requirement, but I also don't want to be scrambling when it becomes mandatory).
The server side is and will remain in Java.
Need good backward compatibility options, as we will not always be able to control the client versions.
The research we've done so far has indicated gRPC (with ProtoBuf) as a strong candidate that ticks all the boxes. The grpc package seems to work great in Electron, and the server coding in Java is very easy. The biggest downside is that, since it uses HTTP/2, we have to jump through hoops to run it in a browser (grpc-web combined with a data proxy).
Are there any good alternatives that use websockets, or other suggestions entirely? Ideally we would like to use the same code when executing in Electron vs. browser.
You could look at WAMP protocol. The lead implementation is Autobhan. It's an RPC & PUB/SUB client-server framework that works by exchanging JSON (or msgpack) messages over websocket. So fits in well with Javascript and browser side.
What is the best technology to use if I want to make instant user notification,
like StackOverflow has?
I consider SSE and WebSockets. What are pros and cons of each solution?
Should I use socket.io or better to use WebSockets directly?
The main difference is that with SSE you can only receive messages from the server. You cannot send messages to the server. Everything doable with SSE is doable with WebSockets. But not vice versa - WebSocket is capable of sending data to the server. So from that point of view WebSockets win. I can't really see any advantage of SSE (perhaps performance?), but then again I don't have much experience with it.
Note that StackOverflow uses WebSockets. They might have some fallback for older browser, I don't know about that.
As for the third question: perhaps you should ask what language you want to use in the first place? I've been working with WebSockets and Python and it worked really well. You could work with WebSockets directly. The advantage of using socket.io is mostly the fallback (assuming it matters - it does not IMHO): if WebSockets are not available it can automatically switch to other ways of communication (like Flash or long polling). The disadvantage is that it is Node.js (in the sense that you have to restrict yourself to one language) plus there are some performance issues, i.e. socket.io does not scale well beyond one machine.
You might consider using a library like SocketIO that abstracts out the transport layer, so you don't have to worry about the mechanics of how the real-time connection is maintained. This will save you a TON of headaches.
I am using Flask and I want to show the user how many visits that he has on his website in realtime.
Currently, I think a way is to, create an infinite loop which has some delay after every iteration and which makes an ajax request getting the current number of visits.
I have also heard about node.js however I think that running another process might make the computer that its running on slower (i'm assuming) ?
How can I achieve the realtime updates on my site? Is there a way to do this with Flask?
Thank you in advance!
Well, there are many possibilites:
1) Polling - this is exactly what you've described. Infinite loop which makes an AJAX request every now and then. Easy to implement, can be easily done with Flask however quite inefficient - eats lots of resources and scales horribly - making it a really bad choice (avoid it at all costs). You will either kill your machine with it or the notification period (polling interval) will have to be so big that it will be a horrible user experience.
2) Long polling - a technique where a client makes an AJAX request but the server responds to that request only when a notification is available. After receiving the notification the client immediately makes a new request. You will require a custom web server for this - I doubt it can be done with Flask. A lot better then polling (many real websites use it) but could've been more efficient. That's why we have now:
3) WebSockets - truely bidirectional communication. Each client maintains an open TCP connection with the server and can react to incoming data. But again: requires a custom server plus only the most modern browsers support it.
4) Other stuff like Flash or Silverlight or other HTTP tricks (chunked encoding): pretty much the same as no 3). Though more difficult to maintain.
So as you can see if you want something more elegant (and efficient) than polling it requires some serious preparation.
As for processes: you should not worry about that. It's not about how many processes you use but how heavy they are. 1 badly written process can easily kill your machine while 100 well written will work smoothly. So make sure it is written in such a way that it won't freeze your machine (and I assure you that it can be done up to some point defined by number of simultaneous users).
As for language: it doesn't matter whether this is Node.js or any other language (like Python). Pick the one you are feeling better with. However I am aware that there's a strong tendency to use Node.js for such projects and thus there might be more proper libraries out there in the internets. Or maybe not. Python has for example Twisted and/or Tornado specially for that (and probably much much more).
Websocket is an event-driven protocol, which means you can actually use it for truly real-time communication.
Kenneth Reitz wrote an extension named Flask-Sockets that is excellent for websockets:
Article: introducing-flask-sockets
Github: flask-sockets
In my opinion, the best option for achieving real time data streaming to a frontend UI is to use a messaging service like pubnub. They have libraries for any language you are going to want to be using. Basically, your user interfaces subscribe to a data channel. Things which create data then publish to that channel, and all subscribers receive the publish very quickly. It is also extremely simple to implement.
You can use PubNub and specifically PubNub presence meant especially for online presence detection. It provides key features like
Track online and offline status of users and devices in realtime
Occupancy to monitor user and machine presence in realtime
Join/Leave Notification for immediate updates of all client connections
Global Scale with synchronized servers across the PubNub Data Stream Network
PubNub Presence Tutorial provides code that can be downloaded to get presence up and running in a few minutes. Five Ways You Can Use PubNub Presence shows you the different ways you can use PubNub presence.
You can get started by signing up for PubNub and getting your API keys.
I'm new in the WebRTC and Websockets world. I'm interested in making an 1 vs 1 web game.
The problematic is just : How to send simple variables (mainly numbers) from a client to the other client ?
I have a Node.js server with websockets (via socket.io).
So, for the clients, I have two solutions :
Using Websockets : The client 1 push the var to the server and the
server push the var to client 2. This solution allow me to easily adapt my application for many users in one game.
Using WebRTC : The offer and the answer are sended via the server with websockets. Then, the client 1 push the var to the client 2 via DataChannel (I don't need getUserData)
I prefer using WebRTC because it eases the work of the server, that allow him to manage more clients.
So I set up the two solutions to compare and, big surprise ! Websockets are highly faster than WebRTC !
My test is simple : just a cube rotating using Three.js, the first client make a little rotation at each frame (60 per second) and push the rotation result to the client 2. At the reception, the client 2 update the rotation and render.
With Websockets, the result is perfect but with WebRTC, the client 2 runs really slow, like 5 FPS.
Is that the problem is the way I'm doing it ? Is it normal ?
I'm working on localhost, on Firefox.
The problem is with WebRTC. The WebRTC DataChannel implementation on Chrome (probably the same goes for firefox) is limited to around 30 kbps. I don't know the reason why? Something about not flooding the internet. There is a hack to circumvent this limitation - manually changing the "B=" filed in the SDP before setting it.
However... WebRTC is p2p UNRELIABLE communication. This means that you have to take extra care to ensuring that no messages are lost and the two players observe the same events and environment. I would go with websockets just because they are so much easier, understood and supported. If the game goes viral I would consider WebRTC as a possible optimization.
However if you are doing this game just for fun then you will learn a lot of useful stuff if you choose WebRTC.
If you want to see an example how webrtc is used in real projects take a look at:
http://viblast.com/demo
NB! After the introduction of SCTP-based data channels at around the Chrome 31-32 time there is no bandwidth throttling any longer and there is a new mode of operation which allows for reliable data channels.
I wanted to be allow users to play p2p in a multiplayer game that I'm developing, but to be able to do that, javascript needs to be able to create a socket server in the browser. Is that even possible? I don't know of any API that let clients connect to other clients in javascript. Is there any other way? Like using a hidden flash element?
I am asking for something that doesn't require a server at all. The packets need to travel from client to client directly
In short no, p2p in a browser is not possible.
The closest you can get is using NodeJS (for potentially p2p JS) or a centralised server (or several servers) and websockets (for sockets in a browser)
This question is old, but I can now give an answer: YES, there is finally a way to do p2p communication between browsers!
Thanks to the new standard WebRTC, modern browsers got support for Data Channels, something much more powerful than WebSockets.
Take a look here:
WebRTC Data Channels
Online Example: Banana Bread 3D is a First Person Shooter game compiled to JS+WebGL, using WebRTC data channels in multiplayer mode:
BananaBread 3D Multiplayer online fps game
Interesting question, but probably a duplicate:
What techniques are available to do P2P in the browser?
i know for sure this can not be done using only javascript(in every browser). According to another answer on Stackoverflow in above topic you might be able do this using rtmfp-api.
This project expose Rtmfp protocol (provided by Flash version 10) to
javascript application throught a hidden flash applet. The protocol
allow multiple clients to communicate directly. See the references for
more details about the protocol.
Looking quickly at the site you still need a rtmfpUrl-server in the middle, which i totally understand because the clients need to be be able to find each other(IPs). But I assume after that it will be p2p. Doing a quick search I also found open-source rtmfp-server(s).
I haven't tried this out myself, but I maybe this will help you achieve your goal.
Some other links:
https://stackoverflow.com/search?q=browser+p2p
https://stackoverflow.com/a/7933140/11926
https://stackoverflow.com/a/5211895/11926
https://stackoverflow.com/a/5023048/11926
While this is a shopping question, i'd look into APE
http://www.ape-project.org/
At the very least you could check out how they've structured it.
In order to implement such a game, your JavaScript client must communicate with the server. The server then runs the game logic, and sends the result back to the client.
JavaScript receives user input and sends it to the server
Server ensures that the input is valid (to prevent cheating) and updates the game with the new input
Server periodically sends the game state to JavaScript (either by long polling or by having JS request it at an interval).
Basically, never trust anything coming from JavaScript as it is extremely easy to modify. Everything should be done server-side.
Here's a solution with mobl (but I haven't tried it yet).
http://zef.me/3391/moving-the-server-to-the-browser
It is possible to go serverless with Flash. This is doable with Adobe Flash's Peer to Peer capabilities. I once wrote a peer to peer chat with it. The drawback is Actionscript is a dying language and may not be supported much in the future.
Here is the raw class.
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/net/NetGroup.html
Here is resources if you don't want to write your own.
http://www.as3gamegears.com/category/multiplayer/
If you want a Server option that is light on the server side. Try this node.js extension.
http://socket.io/
I recommend using a java socket server of some sort. Electroserver used to be one of the leaders in the field, it had Unity support and was scalable to hundreds of thousands. Although I think they have fallen on hard times. The Electroserver site has not been accessible for sometime. I know there are others out there but Electroserver is the only one I have used.