Awhile ago I was looking around for SQL connectivity with my embedded devices and people recommended not to use ODBC because it would not be able to maintain a constant connection if it were wifi etc. So they recommended I just connect using HTTP requests for data-entries etc. So is this possible and if so what do the requests typically look like?
Btw I would use SSL/TLS for encrypted connection because plaintext over the internet is a nono.
Also this would help because all I have learned was microsoft's ODBC library and I relied on it a lot because now I don't know how to connect to MySQL database from Linux as I have not seen a C++ odbc library, so learning the HTTP way would make it more universal.
Related
I tried to build a server for integrating the webrtc native APIs in an native app, but I am not sure about how the server should be configured, like the ICE/STUN/TURN, signaling, media server etc..
So far as I know is the open source project: https://github.com/priologic/easyrtc
Can anybody give some recommendations?
Thanks
In a WebRTC infrastructure, there are several things involved. The client part is written in JavaScript and runs on the browser.
But as you said it is a server side part. First there is a ICE/STUN/TURN server that it's used for a client to discover its public IP address if it is located behind a NAT. Depending on your requirements could not be necessary to build/deploy your own server, but use an already public (and free) existing one - here's a list. You can also deploy an open source one like Stuntman.
Then it comes the signaling part, used by two clients to negotiate and start a webrtc session. There is no standard here and you have a few options.
You can use an XMPP server with a Jingle extension. You can deploy an existing XMPP server, like OpenFire or Tigase
You can also use SIP, a protocol much more encountered for VoIP. You can use JAIN-SIP or SIP Servlets.
Or you can develop your own signaling protocol using something like websockets.
The server side options that I was giving you were Java based ones, but you can find similar for other infrastructures too.
STUN/TURN is required. Use public ones (not absolutely stable) or get a Ubuntu machine ans install from the source: https://code.google.com/p/rfc5766-turn-server/
Signaling is trivial. You just forward messages between peers. Just build a simple chat server.
Media server is whole different story and require sophisticated client-server configuration.
We use a particular ODBC driver here to access a legacy database. Our homemade software (a 2 tier vb.net winform application that connects to an sql-server database) could really use it for some operations. Unfortunately, due to licencing restrictions we cannot deploy the ODBC driver on more than one computer. I'm looking for a way to go around that.
My initial thought was a WCF service and POCOs. However, since the app references a library with a rich set of generic ADO.NET helper functions, I really want to reuse these to communicate with the server. So I'm thinking of making my own ADO.NET implementation to access the WCF service that will, in turn, expose session objects to process queries sent by the client.
Anybody did something like this before? What challenges awaits with implementing my own ADO provider? Also, is there something like this that already exists, before I go and reinvent the wheel?
You can use an ODBC-ODBC Bridge to access you legacy ODBC driver from any other machine and still access it via ODBC. Sounds to me like this would be a lot less effort.
Update: I can only describe the Easysoft ODBC-ODBC Bridge as I've not seen the code of any other bridge. At the client end you install the OOB client ODBC driver. On the server end you install a service. The client end effectively sends your ODBC calls and data to the server where they are redirected to the actual ODBC driver you want to use. Of course, there are loads of optimisations performed both in the ODBC APIs and the protocol. There are a lot of advantages to this a) you can use a driver you cannot get for the platform you want to code on b) you can use a 32 bit application to talk to a 64 bit driver or vice versa c) you might only be able to or want to use one license for the driver/database on the server d) you can cross networks to access a remote driver etc.
Transactions are handled properly in the Easysoft OOB.
I've spent hours now looking for an answer to this question and I can't seem to find it anywhere.
Are there any tutorials or sample code that help with setting up an http connection so that a user can use the browser to save the application coredata sqlite file to the desktop and/or send a previous sqlite backup to the app?
Thanks in advance.
You can use the Cocoa HTTP Server. I have used it before, and it works great.
It has:
Built in support for bonjour broadcasting IPv4 and IPv6 support
Asynchronous networking using GCD and standard sockets
Password protection support
SSL/TLS encryption support
Extremely FAST and memory efficient
Extremely scalable (built entirely upon GCD)
Heavily commented code
Very easily extensible WebDAV is supported too!
Is there a framework or class that allows Cocoa and Objective-C to interface with a remote database, be it SQLite, MySQL, or another (though preferably SQLite)?
You can download the source and compile this yourself but I have read that it is a pain and I think the project may be dead:
CocoaMySQL-src
However, connecting to a remote DB directly from an iPhone/iPad App is a very bad idea. Imagine someone with a jailbroken iPhone and a simple packet sniffer.... It would be incredibly easy for someone to compromise the security of your Database.
The best way to acomplish this is to wrap it in php via a web server on your remote Database server. You can then run a query on the DB with a simple http POST request and have the page return xml/json/whatever.
I am working on a project that involves an embedded system which runs a non-microsoft OS with a C program for the application and am developing .NET software for its end user applications. For remote configuring with the .NET software (which can go across firewalls), I am considering using WCF. I know only a little about WCF so far but I've read that it is supposed to be interoperable with environments other than .NET. The embedded environment has an HTTP stack but no built in support for web services. Does anyone have any experience with this kind of thing or know if it would be appropriate at all? If so please provide some advice or point me in the right direction.
Thanks!
WCF is interoperable because it's accessed over HTTP. Visual Studio can help you build client libraries very quickly for WCF, but client access to WCF doesn't require anything other than HTTP calls with the proper payload. If you're looking at a remote server call and your built-in support in your embedded environment is basic HTTP, look at building your server-side as REST-formatted methods. Your debugger will thank you.
What kinds of data are you planning on transferring back and forth? For something this low level and proprietary I would recommend sticking with good old fashioned Sockets.
I will be passing configuration data back and forth...basically to enable technical support staff to remotely program the device. If I were using sockets this could be binary data, but there is a requirement that customers with firewalls shouldn't need to open any ports. Because of this I was thinking of sending XML over HTTP. So, is it better to use WCF or REST on the server side? Or WCF with REST?
I'm curious about your "customers with firewalls" requirement. Sockets with binary data or XML over HTTP can use any port (not just port 80), and I'm curious if your device will be "listening" on the network, or just making an outbound connection. If your device is listening, you will need to open a port on the firewall. Making an outbound connection ("phoning home") is much easier on the firewall.
So I think you could use sockets and binary data. However, I have faced similar issues on the last two projects, and I really wanted to implement WCF using REST on the embedded device, but no one else wanted to do it - I'm hoping someone else will be first, and publish some results!
Good Luck! (and post your results!)