I am wondering about the limitations of using libraries in code name one. Specifically, I would like to use a specific http client library that uses nio but I am not sure if that will even work in code name one. There is an http1 client and an http2 client here
https://github.com/deanhiller/webpieces
Can the nio stuff actually be compiled into iOs? or does it have to be synchronous socket http client implementations?
thanks,
Dean
It won't work and you can't. This article is from 2016 but it's still mostly accurate. The gist of it is that most of these APIs aren't essential and if we add all of them performance/size would balloon to huge numbers.
E.g. a Codename One application can weigh less than 3mb for iOS production builds with 32 and 64 bit support. Our closest competitors clock at 50mb for the same functionality with only 64bit support. This isn't just a matter of size, it's a matter of quality (QA), maintenance etc.
This also reduces portability as we have to test this on all ports including iOS, UWP, Web etc.
Having said that we're open to adding things and have added some features to the core since the publication of that article. But either way, you can't just use an arbitrary jar and need to use a cn1lib.
Related
I'm interested in studying the 9P FS, currently been reading the source available from these implementations: http://9p.cat-v.org/implementations
Is 9P obsolete? Are you using it for some application?
(also I've found this, some perfomance test between 9P and NFS: http://graverobbers.blogspot.com/2007/08/v9fs-performance-versus-nfs.html)
No, 9P isn't obsolete; I don't know of a protocol that does what it does and is clean and well defined enough to be implemented correctly in almost any language that exists.
9P is used in a variety of systems. A couple of recent uses in arm-js (an ARM emulator) and 9webdraw (a GSoC project that implements the Plan 9 /dev/draw). Both are HTML5 Javascript implementations.
Just to add a bit, both the Linux client implementation and several servers are under active development, so I'd say that's a pretty clear sign that folks still have use for it. One of the areas its seen heavy use more recently is the virtio-9P (aka virtfs) which is part of qemu/kvm and can be used for direct guest to host file access. It's also been used in several experimental operating systems projects (Libra, PROSE, FusedOS) and incorporated into other operating systems (BSD, MacOSX, Windows, Linux) and hypervisors (in addition to the KVM instance above, its also been incorporated in various ways into Xen). 9P is actually being used in supercomputing deployments (both for Plan 9 and Linux, see the diod project on Sourceforge).
I think the reason is that the protocol is quite simple, so implementations also tend to be quite simple and easy to integrate elsewhere (there are several applications both inside and outside the Plan 9 world which use 9P as an interface to the application, in much the same way that some web developers use RESTful interfaces).
The protocol has a couple of different variations including the 9P.L variant which was developed specifically to match the Linux VFS API better. It adds a bit of complexity to the protocol in the addition of operations, but removes some of the complexity of mapping Linux VFS API -> 9P and vice versa.
It is used in Erlang-on-Xen both as a storage protocol for goofs http://erlangonxen.org/blog/goofs-simple-filesystem
It is the way erlang on xen instances in other ways too, see here:
http://erlangonxen.org/more/9p2000e
Also, it's used by libvirt stuff with QEMU.
http://wiki.qemu.org/Documentation/9psetup
9p, to me, is like the Scheme of network protocols. For the most part, it is very simple, but people see need to extend it to fit their environments. Luckily this is done in ways that are often backwards compatible.
In addition to everything mentioned in the other answers, Microsoft is using 9P as part of their Windows Subsystem for Linux.
They add a 9P server to each Linux distribution that is running as a guest, so that Windows can mount the Linux filesystem over 9P, and Windows processes can transparently access the files on Linux's ext4 partition.
Is there any high performance (ideally evented and open source) web server in C or C++?
I'd like to be able to use it in that it calls a method/function in my application with a filled out HTTP Request class/struct, and then I can return a filled out HTTP Response class/struct to it.
If it isn't open source, I'd need built in support for long-polling connections, keep-alive, etc—otherwise, I think that I can add these things myself.
If you don't know of any such servers available, would you recommend writing my own web server to fit the task? It cannot be file-based, and must be written in high-performance C/C++.
Edit: I'm thinking something like the Ruby Mongrel for C, if that helps.
I had the very same requirements for my job, so I evaluated a number of solutions: mongoose, libmicrohttpd, libevent. And I also was thinking about writing nginx modules. Here is the summary of my findings:
nginx
nginx project page
I love this server and use it a lot. Its performance and resource usage is much better than that of Apache, which I also still use but plan migrating to nginx.
Very good tunable performance. Rich functionality. Portability.
Module API is not documented and seems to be very verbose. See this nginx hello world module as example.
Nginx does not use threads but uses multiple processes. This makes writing modules harder, need to learn nginx API for shared memory, etc.
mongoose
mongoose project page
All server's code is in single mongoose.c file (about 130K), no dependencies. This is good.
One thread per connection, so if you need concurrency you've got to configure lots of threads, ie. high RAM usage. Not too good.
Performance is good, although not exceptional.
API is simple but you have to compose all response HTTP headers yourself, ie. learn HTTP protocol in detail.
libmicrohttpd
libmicrohttpd project page
Official GNU project.
Verbose API, seems awkward to me, although much more simple than writing nginx modules.
Good performance in keep-alive mode (link to my benchmarks below), not so good without keep-alive.
libevent
libevent project page
Libevent library has built-in web server called evhttp.
It is event based, uses libevent for that.
Easy API. Constructs HTTP headers automatically.
Officially single-threaded. This is major disadvantage. I've found a hack, which makes several instances of evhttp run simultaneously accepting connections from the same socket. Not sure if it is all safe and robust.
Performance of single-threaded evhttp is surprisingly poor. Multi-threaded hack works better, but still not good.
G-WAN
G-WAN project is not open source, but I'd like to say a few words about it.
Very good performance, low memory usage, 150 KB executable.
Very convenient 'servlet' deployment: just copy .c file into csp directory, and running server automatically compiles it. Code modifications also compiled on the fly.
Simple API. Although constrained in some ways. Rich functionality (json, key-value store, etc.).
Unstable. I had segfaults on static files. Hangs on some sample scripts. (Experienced on clean install. Never mixed files of different versions).
Only 32-bit binary (not anymore).
So as you can see, none of existing alternatives have fully satisfied me. So I have developed my own server, which is ...
NXWEB
NXWEB project page
Feature highlights:
Very good performance; see benchmarks on project page
Can serve tens of thousands concurrent requests
Small memory footprint
Multi-threaded model designed to scale
Exceptionally light code base
Simple API
Decent HTTP protocol handling
Keep-alive connections
SSL support (via GNUTLS)
HTTP proxy (with keep-alive connection pooling)
Non-blocking sendfile support (with configurable small file memory cache; gzip pre-encoded file serving)
Modular design for developers
Can be run as daemon; relaunches itself on error
Open source
Limitations:
Depends on libev library (not anymore)
Only tested on Linux
I would suggest to write a FastCGI executable that can be used with many high performance web servers (even closed source ones).
mongoose: one file. simple and easy to use. not an asycn io but perfect for embedded and particular purposes.
gwan. excellent. no crashes. ultra well planned configuration. very smart and easy for c/c++ development in other words, very clean sensible api compared to nginx. provides a thread per core. or whatever you specify. a great choice. largest disadvantage (maybe im lacking in this area): cannot step thru code.
libevent: single thread is not a disadvantage on a single core machine. afterall its point is an async i/o. does have multithreads for other cores.
nginx: no personal experience. gaining serious ground on a-patchy server. (terribly confusing api)
boost asio: a c++ library for asynchio (asio). awesome. needs a friendly higher-level api for simpletons like myself. and others who come from php, java, javascript, node.js and other web languages.
python bottle: awesome 1 file lib (framework/system) that makes it easy to build python web apps. has/is a built in httpd server, like libevent and node.js
node.js: javascript asyncio server. an excellent selection. unfortunately, have to program in javascript that does become tedious. while there is something to be said for getting the job done; there is also something to be said for enjoying yourself during the process. hopefully no ones comes up with node.php
I'm going to suggest the same thing as Axel Gneiting - but have provided an answer with my reasons for taking this approach:
1) HTTP is not trivial as a protocol - writing your own server or amending an off-the-shelf solution is a very complex task - a lot more complex than using the available APIs for implementing a separate processing engine
2) Using (an unmodified) mainstream webserver should provide you with more functionality than you require (so you've got growing room).
3) Using (an unmodified) mainstream webserver will usually mean that it has been far more extensively tested and documented than a homebrew system.
4) .. and its more likely to be secure and stable.
5) Using fastCGI you can use all sorts of languages to develop your back-end processing in - including C++ and C. There are standard toolkits available to facilitate this.
6) alternatively many webservers provide support for running interpreter engines in-process (e.g. mod_php, mod_perl). I'd advise against running your own native code as a module though.
It cannot be file-based.
Eh? What does that mean?
I'm an avid nginx user; nginx is written in C; nginx seems like it could work for you. If you want the very best speed out of nginx, I would make a nginx module. Here are 3rd party modules which you can examine to get an idea of what it requires.
As for the long polling requirement, you might want to have a look at the http push modules.
I need to create a web-controlled application (that lives in the browser) that can connect to and read data from devices connected via USB or the serial port.
At the moment, I'm using an ActiveX control to do this. However, I'm like to re-write this system to make it cross-browser (support Firefox) and eventually cross-platform (support Safari on Mac). ActiveX is neither cross-browser or cross-platform, so I'm looking for an alternative technology.
My first inclination would have been to use Silverlight, because Silverlight 4 grants access to COM Automation. Unfortunately, this only works with OOB (Out of browser) Silverlight applications - in-browser systems are still bound in a sandbox and do not have access.
So, what technologies exist (frameworks, browser plug-ins, etc) that will allow me to interface with a USB/Serial device from within a browser-based web application? What are the pros/cons of each?
I think your best bet is probably Java in this case. USB, though an industry standard in terms of protocol is definitely not standardised in terms of bare-metal implementation. For this reason, you will still need a different Java USB implementation for each distinct platform (windows, linux, osx, bsd) that you intend to support. Of course you will also have to pay for code-signing certificates so you can try to convince people to grant your application the kind of access it requires; something that browsers try very hard to deny access to and most people in this day and age are very unwilling to grant. That said, there's an old IBM article here on the various Java USB projects that makes a good read. Good luck.
http://www.ibm.com/developerworks/library/j-usb.html
-Oisin
It might be painful, but you could use a signed Java applet. Signed Java applets can have full access to the user's system.
Java does not have built in USB support, so you would probably need to roll your own JNI interface to native USB APIs.
Using JNI in an applet can be tricky. I've done it before. If you Google the topic, most results say "don't do it" or "you can't do it." Well, you can do it.
This is how I did: I packaged the native libraries (DLL, so, etc) inside the applet's JAR, and then read the native libraries out of the JAR using e.g. getResourceAsStream. I then wrote the libraries out to an appropriate location on disk (e.g. ${user.home}/.myapp/.) I then used System.load to load the JNI DLL.
There can be some ClassLoader issues with JNI libraries and applets. The issues are subtle and difficult to explain. They basically have to do with the fact that a JVM can only load and bind a given JNI library once per VM instance, but applets get instantiated a lot, often with their own new ClassLoader, which can be problematic. The work that Sun did on process separation in the Next Generation Browser Plugin may have relieved some of these issues, but your users will only have this if they are using Java 1.6.0_10 or later.
It is also possible to use JNA within a signed applet. I would not recommend using JNA to access USB APIs directly. But JNA can sometimes be a big time saver for accessing simple native functions. Although once you've set up your JNI infrastructure, JNA probably has less value.
Here are a few other random thoughts:
Java WebStart - Can be launched from browser, but runs outside the browser
Microsoft ClickOnce - Can be launched from browser, but runs outside the browser
Flash / AIR - Can't escape its sandbox
The best solution I've come across thus far is the cross-browser/cross-platform plug-in system called FireBreath. This is a framework built in C++ that allows you to generate plug-ins for both ActiveX and NPAPI from the same codebase.
So build it once, make it work, and it compiles to one DLL that you can deploy in either environment: ActiveX for IE, NPAPI for everyone else.
Is there a cross platform C API that can be used to get system usage metrics?
I've worked with libstatgrab before. Gets you some pretty useful system statistics for the main Unix-like variants and Windows through Cygwin (supposedly - never tried). Different OS's work so differently - especially when it comes to usage metrics - it may be challenging to get what you want. Even something as simple sounding as "free memory" can be tricky to act on in a cross-platform way. Perhaps if you narrow things down a bit, maybe we can find something.
Unfortunately not.
The C standard is pretty much limited to dynamic allocation, string manipulation, math and text I/O. Once you get beyond that, you need OS APIs which by definition are OS specific and not cross platform.
Depending on the metrics you want to collect, you may want to consider looking at PCP (Performance Co-Pilot). This is an open-source performance framework, originally developed at Silicon Graphics, which collects and collates a vast number of possible metrics from a vast number of sources, and lets you monitor them from anywhere.
Basically PCP would involve adding another 'layer' into your system -- for example, you might monitor a distributed cluster of mixed-OS machines, each with PCP installed locally; a set of 'agents' collect the performance data on each machine, and your code could then use libpcp to collect those metrics as required.
It's hard to say without knowing your exact usage scenario (if you're talking about something running seamlessly on end-users' machines, PCP may not suit but if you want to monitor machines which you control, and are happy to run the PCP service on them, it's an awesome solution).
We use PCP very happily to collect metrics from Windows and Linux boxes, as well as internal metrics from our application, and log them all centrally, report on them, monitor trends, etc.
The good old SNMP provides C libraries for the client and server side. If you prefer something newer you should try Prometheus. They have Node Exporter ready to use and the client libraries for many languages including C.
Also note that PCP (mentioned in Cowan's answer) supports the OpenMetrics standard since version 4, so if you decide to use Prometheus as the metric data collector extending PCP or writing a custom Prometheus client are better solutions that SNMP which also supported by Prometheus through SNMP Exporter, but more difficult to set up due to the way it handles MIBs and authentication.
My stuff is made with several components among which some are written in C. As I would like to add some security features, I am thinking of communicating over an SSL/TLS layer.
Could you advise me some good lib to do this (if possible) ?
GnuTLS (Please note that it is mainly LGPL not GPL so you can link to it). At least I prefere it's API over OpenSSL.
Also there is Mozilla's NSS.
We use axTLS which works great on both our server (.NET) and our embedded systems (Linux and uClinux). We had problems getting OpenSSL to work well on uClinux.
axTLS is not as feature complete as OpenSSL yet so make sure it meets your requirements before using it.
How about OpenSSL?
I would suggest not spending your time trying to implement an SSL function in your app. Instead, you could just use an existing SSL-tunnel software, which creates an SSL tunnel in front of your existing socket application.
Internet --- [SSLTunnel] --- Your App
For example, you could tell the SSL tunnel to listen on port 443 (https) and forward all decrypted packets to port 80 (http). For your custom application, it will just see decrypted packets.
There are plenty of free apps that do it. Just google for one.
CyaSSL would be an excellent choice to consider. This is an embedded SSL library written in C which has been optimized for speed and size. It can be up to 20 times smaller than OpenSSL, and can be quite a bit faster as well.
Among the feature list are a minimum size of 30-100kb and an OpenSSL compatibility layer. The full feature list can be found on the yaSSL website here:
http://www.yassl.com/yaSSL/Products_cyassl.html.
It is dual licensed under the open source GPLv2 as well as a commercial license (for support). It is updated very frequently with new features. I think one of the cool features is support for the RABBIT and HC-128 stream ciphers from the eStream project.