+1  A: 

You can define RESTful services the use HTTPS (which uses TCP/IP by definition) and is capable of transferring any amount of data.

The advantage of REST over SOAP is that REST is simpler. It can use JSON instead of XML which is simpler.

It has less overhead than the SOAP protocol.

S.Lott
Thanks, Steven, that looks like a good option.
Peter K.
+1  A: 

Can't you just use SSL over TCP?

If you have some kind of *nix (may I guess? It's either QNX or embedded linux, right?) it should work pretty much out of the box via Ethernet, USB and RS232. Keep thing simple.

32mb is plenty of memory for this task. I would allocate between 2 and 4 mb of memory for networking & encryption (code + data).

Nils Pipenbrinck
Nils, thanks. Yes, SSL over TCP would work. We're just wanting a bit more structure than just "bit-banging" across an encrypted line.
Peter K.
+1  A: 

It's not real clear why you want to tie this to a remote-procedure-call protocol like SOAP. Are there other requirements you aren't mentioning?

In general, though, this sort of thing is handled very easily using normal web-based services. You can get very lightweight http processors written in C; see this Wikipedia article for comparisons of a number of them. Then a REST interface will work fine. There are network interfaces that treat USB as a TCP connection, as well.

If you must be able to run over RS232, you might want to look elsewhere; in that case, something like sftp might do better. Or write a simple application-layer protocol that you can run over an encrypted connection.

Charlie Martin
Thanks, Charlie! The SOAP suggestion was because that's the way the enterprise architecture we're fitting into hangs things together. It would make our embedded device just look like another box. As for the webserver, we've looked at Boa, mini_httpd and thttpd. Mini is the current choice.
Peter K.
Ah! okay, if you're dealing with an existing SOAP application, that changes everything. The RS232 part worries me, though -- if you must have RS232, what will you do to provide HTTP over it?
Charlie Martin
Good question regarding HTTP/RS232! We're waiting on the outcome of a parallel project that will need to do something similar (RS232 comms to an existing device) and we'll triage how that goes once we get there, too.
Peter K.
+1  A: 

If you are going to connect your application using RS232, I assume that you will be using PPP to connect the device to the internet. The amount of data that you are proposing to transfer is somewhat worrisome, however. Most RS232 connections are limited to 115200 baud which, ignoring the overhead required for TCP/IP/PPP framing is going to yield a transfer rate of at most 11,000 bytes per second. This implies that it will take a minimum of approximately 2800 seconds or 46 minutes to make whatever transfer that you intend.

Jon Trauntvein
Thanks, John! I agree, RS232 is not the best way to do data transfers but we need to be able to fit into legacy systems and this is one way the legacy stuff communicates.
Peter K.