Regarding the RPC package "thrift":
I believe this package exists in two forms: the "classic" Apache Thrift, and the somewhat newer "Facebook thrift" (or fbthrift).
I believe that Apache Thrift does not support asynchronous clients which make call that return immediately, coupled with a callback mechanism to notify the client that the server has completed its work. (My previous question, titled "thrift async c++ example" yielded a response confirming this belief).
I believe that fbthrift does a good job in supporting these things, particularly in C++ (and its C++11 variant).
However... my efforts to work with fbthrift led me to conclude that it is unstable as it's being changed pretty frequently.
Does anyone know whether there are stable "point releases" of fbthrift, and if so, how I can access them?
Facebook released Thrift into OSS a while ago. It then went under the wings of the ASF, where it still exists as a TLP today. Facebook then later released their internally used version of Thrift again, containing some new features.
Since then, a number of features have been ported from fbthrift to Apache Thrift. Others are still being discussed. Although I can only speak with authority re Apache Thrift, as far as I know both projects are alive and maintained, and of course mostly compatible.
While fbthrift primarily focuses on what FB needs, Apache Thrift is the version with the broadest language support (last time I counted we were way above 20+ target languages). The last stable release at the time of writing is 0.10.0 from January this year.
Related
Months ago I was selecting .NET library to use for implementing ZeroMQ communication, and I was pretty confused with the fact that there are few libraries suggested at zeromq.org.
Meanwhile I've learned few things, so I'll share here. Someone may find this helpful. So let me ask myself:
What is the difference between NetMQ and clrzmq?
(Although I'll answer this myself, if anyone else has some experience on the subject - alternative answer is welcome!)
The key difference between the two is in the approach:
CLRZMQ is binding project which actually uses libzmq library in background (it's a .NET wrapper for libzmq library);
NetMQ is .NET-native port of ZeroMQ, meaning that it does not wrap existing libzmq but rewrites it in pure C#.
Which one to use? Well, there's no simple answer. Here are few important things to keep in mind while choosing:
When it comes to portability - NetMQ wins by far, especially due to the fact that there's .NET Core version of NetMQ. Deployment is also easier with NetMQ - there are no native libraries to worry about (x64 / x86, etc.).
On the other side the fact that NetMQ actually rewrites everything is bit scary for me - there's always risk that something is not precisely mirrored from the original code, and that it may cause incompatibility with other ZeroMQ nodes. There's also question how fast NetMQ will implement new features from the original library.
Performances. At the moment I don't know which library wins in performances, but this is definitely thing to consider while choosing. libzmq should be significantly faster than any managed code, but in communication between CLRZMQ and libzmq marshaling has to take place, so I really can't predict which library will win in speed.
UPDATE: Another important advantage of NetMQ is support - You'll get the answer in up to day or two, and sometimes within hours.
UPDATE 2: A problem with poller implementation in NetMQ (described here) turned out to be show-stopper problem for NetMQ in my case. Due to this problem I've migrated my projects to CLRZMQ (I may change my mind down the road...) Nevertheless, talking about poller, there's one problem in CLRZMQ documentation you should be aware of, and it's described here
According to Doron Somech:
http://somdoron.com/2013/03/introducing-netmq/
As of 2014 C# binding (CLRZMQ) is no longer maintained and NetMQ is the default choice for ZeroMQ and .Net.
It seems that:
https://github.com/zeromq/clrzmq4
replaced the original CLRZMQ project.
I'm using NetMQ and looking forward to contribute to the project.
P.S. I build same Pub-Sub scenario for NetMQ and native ZeroMQ and didn't find any performance difference. Great work, Doron!
I've used ZeroMQ in the past with with JVM applications via the jzmq library. I am planning on using zeromq on a new project where some of the services are implemented on the JVM. I just discovered jeromq, a pure java implementation of zeromq, and I would like to use it mostly since it is tracking zeromq 3.x and it removes the headache of dealing with jzmq. However, I can't tell from the repo page if it is production ready. Does anyone have experience with jeromq in production?
As the author of the project, I'm a little bit biased.
The reason I made jeromq was I also had some trouble with deploying jzmq having JNI.
The project has a short history but keep improving from feedbacks and contributions.
But it's not a replacement of jzmq. Both project are active and driven by a major community. You can get help from the community and contribute to the projects also.
From the 3.0-SNAPSHOT, it has a API level compatibility. You can switch between jeromq and jzmq easily without changing your code.
Why not write a JNI that would do all the interaction with 0MQ ? This would bring the problem in your hands instead of hoping for some 3rd party library being mature enough or production-ready.
That's what I'd do. The C/C++ API of zeromq is IMHO the most mature of them and, as such, I think it would bring you the most benefit.
Writing a JNI is not hard either so I think this would be a good way to go.
I would like to find a good (up-to-date) Java Trail type beginning tutorial on Websockets, with both Javascript client code and Java server code (that actually works). On the server side, if all I have to do is create a simple socket server or something like that, please tell. I have so far found nothing (although I've googled for hours) that provides the essential basic information like this (except on the client side, which is apparently very easy).
I'm not interested in using existing Websocket server systems (other than starting with a simple copy-paste from a simple tutorial). If you're interested, I'll tell you why below.
I have an open-source project that's been begging for HTML5 since long before it began (from its initial conception many years ago). Getting the two-way communication from Websockets as opposed to long-polling, forever-frames etc. looks like a winner to me. The current version of the (framework) software is HLL "light" - with my typical emphasis on not dragging in extra code. It uses Java SE only, although I intend to build version(s) using EE communications. I can at present easily install the whole framework with room to spare for application components on small devices like cell phones.
I want minimum code.
I pride myself on understanding all the code in the system.
I think it's death to a new open-source project if you have to tell people who want to try it that they have to download and install all sorts of other open-source code to do it.
I don't want my code subject to changes in somebody else's code.
This really shouldn't be all that difficult - if I just find the right documentation.
UPDATE: I no longer need a simple tutorial on websockets. I'm well on my way to having built a production class websocket server and have a very nice browser-based client to use for testing. I am now building a non-browser-based client to go with it. Building a multi-client websocket server that implements the full standard isn't simple, btw. (In hindsight - it's no wonder I didn't get any answers.) And if it's going to work as a stand-alone server for browser-based clients, it needs http (to provide the web pages at least) and other stuff. Not a project for the faint of heart or someone with little time to put into it.
Since first posting, I've been building my own WebSocket server. Dreams that all this would be simple quickly passed. I am however, getting close enough to mention the word "release" as in free Beta for anyone who wants a websocket server. (Notice I'm just "mentioning" the word - I'm still at least a couple of weeks away.) It's a multi-user server that's light-weight and screamingly fast. I'll eventually add http support so no other server will be needed for delivery of web pages (WebSockets are upgraded http connections anyway). I'll also be adding HLL functionality. First thing about that is that it will simplify application. Even though I've worked consistently to maintain "light-weight" status, this whole combination has been a life's ambition and I believe developers will find it amazing for building anything from simple and direct to large scale complex, distributed, intelligent systems.
I've used the most recent version of the standard, which is the final draft version, and will probably be very close if not the same as the final standard; version 1. So far, it works with Chromium (Chrome dev) and Firefox. There is however, apparently some code in their WebKit that provides support for other browsers. I haven't tried that yet. With the browser, I've so far made the connection and pass text messages (large and small) back and forth. That's all I've discovered so far that the browser handles. I take it support for very large text "messages" would really only be used for file transfer in conjunction with HTML5 local storage capabilities. I haven't tried that yet either. Binary transfers will likely be connected to HTML5 streaming video and audio at some point, but I haven't run across any mention of it so far.
I'm currently working on a Java client that will support the full standard, including pings and binary transfers, file transfers - the whole ball of wax. Most of what I need has already been built for the server and its "echo" application which includes message sending just like a client. I will then revisit some of my earliest work to generalize in a nice way when adding the new functionality. Having one or more Java websocket clients in applications will be a good thing in many cases, I think. And it'll give the the full capabilities for web browsers as well, whenever they're ready for it.
I also know that Opera is quite popular among HTML5 enthusiasts. I actually started using the version of the standard that they support so it shouldn't be difficult to add it. (Just fooling around trying to find my way - and got the stuff specific to that version working.) I'm seriously tempted to spend the time putting the support in for that version even though it should become totally obsolete within a few months. It's just that Opera is very good on the other HTML5 stuff and there's a large crowd of enthusiasts using it. On the other hand, they mostly work on the browser-client side, and I don't know if they'll get involved much on building server-side applications.
Blog articles related to my work on WebSockets.
WebSocket Server Demontration, SEPTEMBER 26, 2011
WebSocket Demonstration on Microsoft Internet Explorer, NOVEMBER 16, 2011
WebSockets with Apache Tomcat and HLL, JANUARY 12, 2013
I'm somehow familiar with the ASP.NET MVC and the .NET framework in general (I use it at work).
I've been thinking about starting a personal project (a website). I, however, don't want to be tied to a specific platform (it bothers me A LOT).
This led me to looking into Mono. For what I've seen, though, Mono trails behind Microsoft's .NET in some aspects that are crucial to me (or that I would really like to have available). Some of these are:
LINQ to SQL. The Mono team just now (Mono 2.6) released support for LINQ with help from the DBLinq project. The problems are that DBLinq's main test platform are MS SQL SERVER and SQLite. It seems to me that PostgreSQL and MySQL are a bit abandoned. Also, LINQ to SQL has just been implemented and thus it makes me think when it will become mature.
Hosting of Mono on Linux. Very few of these are available.
Also, I want to be prepared to handle heavy-duty processing on the server (this is a main issue), and Twitter's experience makes me drift away from Ruby on Rails, but if you can prove RoR scales weel (please, show benchmarks/facts and not opinions) I'd be willing to try it.
Should I take my time learning a different web framework, or should I rely on Mono's advances and hosting options for the near future (1~2 years) on platforms other than Windows/SQL Server.
In terms of scalability, I tend to think that C# has an inherent aspect of scalability (strongly typed and ByteCode instead of parsed/interpreted). Am I wrong to think like that?
Are there ways to work with other frameworks in ways that the code won't be hosted on the server (I accept python/ruby/anything VMs and others)
This is an old question so I may be answering more for others than for the original poster:
Hosting
If you write in Mono, you can host on Windows, Mac, or Linux (or Solaris, FreeBSD, and others less dependably). If you are going to host on Windows though, why not just run your Mono app on the real .NET?
Why do you care if it is hosted on Mono if you are not hosting it yourself? You can certainly write an application on Mono using Windows, Linux, or Mac and then host it on a Windows/.NET host if those are the cheapest and easiest to find. Just think of .NET as the MS implementation of Mono.
I had the opposite problem originally. I wanted to host on Linux even though my employer provided a Windows dev environment. I developed in .NET and hosted on Mono/Linux. Mono worked excellently for me in this way.
My current employer is Mac crazy. I just deployed an ASP.NET MVC2 app to our Mac server yesterday. I wrote the whole thing on my MacBook Pro without touching Windows once.
My favourite host for running .NET/Mono on Linux is Linode. The cheapest plan is $20/month but I can host as many apps on the same server as I want. The performance is excellent so anything that is going to run well on a $5/month host is going to run just fine as one of four apps on a Linode instance that is for sure.
Compatibility with .NET
I find it is best to think of Mono as a platform itself rather than as a compatibility solution for your Microsoft apps. Mono supports almost the entire .NET framework. I love this because it is a great framework but I do not really care that it is MS compatible most days.
No offence, but I do not understand at all your implication of "Mono does not support LINQ-to-SQL to my satisfaction so I am considering Ruby-On-Rails". Mono supports LINQ-to-SQL a lot better than Ruby does I will tell you that. You could say that you are sticking with Windows only because you really need LINQ-to-SQL though I suppose. What is more important to you, "cross platform" or "LINQ-to-SQL"?
Mono gives you many choices for data access. If you want an ORM (Object Relational Mapper) like Rails offers then you could go for something like NHibernate, Subsonic, or Castle ActiveRecord for example. With Mono 2.10 you can even use WebMatrix Data. Of course, you could also use good 'ole ADO.NET which is what all this stuff is built on top of anyway.
Oh, and let's not lose site of the fact that Mono does support LINQ-to-SQL. I have only ever used it with SQLite where it worked fine. I agree that it has lagged .NET though. You are probably worried about Entity Framework support now. See my comments above.
To my mind, the question is how does Mono data access compare to Rails data access. My answer: Rails is a bit better integrated (simpler) and Mono is much more powerful and flexible.
Heavy-duty processing
This is where .NET and Mono are really going to shine.
You are correct to think that compiled bytecode is going to be much faster than interpreted code and that static languages like C# will be faster than dynamic languages like Ruby. Of course, everything is implementation dependent in the end.
I also agree that a static language like C# aids scalability in other ways. This is really a matter of personal opinion though. There are certainly people that think that authoring and maintaining a massive solution in a dynamic language is feasible. I do not see many people doing that of course. There is a reason that .NET and Java are the enterprise standards.
Bottom line
Should you learn another web framework? Well, I think you should. It is good for the mind.
Is that other web framework a superior choice to Mono or .NET? Well, it depends on the need of course. I think that Rails folks probably pump out the sites a little faster than the .NET crowd in general. The gap has really closed with ASP.NET MVC2+ though and I would much, much rather maintain and scale a .NET solution than a Rails one. Also, I like C# just fine so I do not find Ruby itself so intrinsically satisfying that I just have to use it. That is just me of course.
Also, just me, but I find Mono to be an excellent cross platform web development framework. I choose it everyday over other solutions. I also find that Mono fits into the majority of the .NET ecosystem (especially the Open Source universe) just fine. Again though, if what you really want is to use the very latest and greatest MS stuff and are hoping that Mono will allow you to run that on Linux or Mac sometimes then you may be disappointed.
If Windows Presentation Foundation (WPF), Entity Framework, or to a lesser extent LINQ-to-SQL are the most important part of your application strategy then Mono is not for you.
If you want a platform that gives you all the great advantages of .NET and runs pretty much everywhere you need it to then Mono is pretty damn hard to beat.
I am trying to get started writing scalable, telecom-grade applications with Asterisk and Ruby. I had originally intended to use the Adhearsion framework for this, but it does not have the required maturity and its documentation is severely lacking. AsteriskRuby seems to be a good alternative, as it's well documented and appears to be written by Vonage.
Does anyone have experience deploying AGI-based IVR applications? What framework, if any, did you use? I'd even consider a non-Ruby one if it's justified. Thanks!
SipX is really the wrong answer. I've written some extremely complicated VoiceXML on SipX 3.10.2 and it's been all for naught since SipX 4 is dropping SipXVXML for an interface that requires IVRs to be compiled JARs. Top that off with Nortel filing bankruptcy, extremely poor documentation on the open-source version, poor compliance with VXML 2.0 (as of 3.10.2) and SIP standards (as of 3.10.2, does not trunk well with ITSPs). I will applaud it for a bangup job doing what it was designed to do, be a PBX. But as an IVR, if I had it to do all over again, I'd do something different. I don't know what for sure, but something different. I'm toying with Trixbox CE now and working on tying it into JVoiceXML or VoiceGlue.
Also, don't read that SipX wiki crap. It compares SipX 3.10 to AsteriskNOW 1 to Trixbox 1. Come on. It's like comparing Mac OS X to Win95! A more realistic comparison would be SipX 4 (due out 1Q 2009) to Asterisk 1.6 and Trixbox 2.6, which would show that they accomplish near identical results except in the arena of scalibility and high-availability; SipX wins at that. But, for maturity and stability, I'd advocate Asterisk.
Also, my real world performance results with SipXVXML:
Dell PowerEdge R200, Xeon Dual Core 3.2GHz, handles 17 calls before jitters.
HP DL380 G4, Dual Xeon HT 3.2 GHz, handles 30 calles before long pauses.
I'll post my findings when I finish evaluating VoiceGlue and JVoiceXML but I think I'm going to end up writing a custom PHP called from AGI since all the tools are native to Asterisk.
You should revisit Adhearsion as v0.8.1 is out, and the documentation has gotten much better quite recently. Have a look here:
http://adhearsion.com
http://docs.adhearsion.com
http://api.adhearsion.com
If you're looking for "telecom-grade" applications, you may want to look into SipXecs instead of asterisk. It's featureful, free, and open source, with commercial support available from Nortel. You can interact with it via a Web Services API in ruby (or any other language).
See the SipXecs wiki for more information. There's a comparison matrix on that site, comparing features with AsteriskNOW and TrixBox.
There really aren't any other frameworks out there. There's of course AGI bindings to every language, but as far as full-fledged frameworks for developing telephony applications, we're just not there yet. At least in the open-source world.
I have asked somewhat related questions here, here, and here. I'm using Microsoft's Speech Server, and I'm very intested to learn about any alternatives that are out there, especially open source ones. You might find some good info in the answers to one of those questions.
I used JAGIServer extensively, even though it's not under development anymore, and it's pretty good and easy to use. It's an interface for FastAGI, which I recommend you use instead of simple AGI.
The new version of this framework is OrderlyCalls which seems to have a lot more features but since I haven't needed them, I haven't tried it.
I guess it all depends on what you want to do with AGI; usually I have a somewhat complex dialplan to gather and validate all user input and then just use AGI to connect to a Java application which will read some variables, do some stuff with it (perform operations, queries, etc etc) and then sets some more variables on the AGI channel and disconnects. At this point, the dialplan continues depending on the result of the variables set by the Java app.
This works really fast because you have a ServerSocket on the Java app, which receives incoming connections from AGI, creates a JAGIClient with the new socket and a new instance of a JAGIProcessor (which you have to write, it's the object that will do all your processing), and then run the JAGIClient inside a thread pool.
Your JAGIProcessor implements the processCall method where it does all the work it needs, interacting with the JAGIClient passed as a parameter, to read and set variables or do whatever stuff the AGI interface allows you to.
So you have a Java app running all the time and it can be a simple J2SE app or an EE app on a container, doesn't matter; once it's running, it will process AGI requests really fast, since no new processes have to be started (in contrast to simple AGI which runs a program for every AGI call).
Smee again. After migrating my client's IVR's over from SipX to Asterisk utilizing PHPAGI, I must say that I haven't encountered any other architecture that anywhere near as simple and capable. I'll be stress testing Trixbox CE 2.8 today on the same hardware I had tested SipX on earlier. But I must say, using PHPAGI for the IVR and the Asterisk CLI for debugging has worked perfectly and allowed me to develop IVR's far faster than any other company out there. I'm working on implementing TTS and ASR today and I'll post my stress test results when I can.
Simple small flexible Asterisk AGI IVR written on PHP
http://freshmeat.net/projects/phpivr
For small and easy applications I use Asterisk::AGI in perl. There are also extensions for the Fast AGI. For bigger applications, like VoIP operator's backends I use something similar to OrderlyCalls written in Java (my own code). OrderlyCalls is great though to start with java fastagi engine and extend it to your needs.