EmbeddedRelated.com
Forums

Looking for simple file transfer

Started by Arlet Ottens February 4, 2011
On 2011-02-04, Arlet Ottens <usenet+5@c-scape.nl> wrote:
> > I'm working with some small embedded devices that need a software upgrade > capability through TCP/IP. I'm looking for a simple and lightweight > protocol to send some files. > > I'm aware of TFTP, which would be a candidate, but I'd rather have > something based on TCP and not UDP. FTP is too big.
SFTP - for disambiguation the "Simple File Transfer Protocol" or RFC 913 - comes to mind which is between TFTP and FTP in terms of complexity and runs over a single TCP port. It isn't entirely clear what you mean by a "standard" tool - already installed or available off the shelf. I'd imagine SFTP must be in the latter camp - probably a free download - but I don't know any clients of the top of my head. -- Andrew Smallshaw andrews@sdf.lonestar.org
On Fri, 04 Feb 2011 16:23:02 +0000, Andrew Smallshaw wrote:

> On 2011-02-04, Arlet Ottens <usenet+5@c-scape.nl> wrote: >> >> I'm working with some small embedded devices that need a software >> upgrade capability through TCP/IP. I'm looking for a simple and >> lightweight protocol to send some files. >> >> I'm aware of TFTP, which would be a candidate, but I'd rather have >> something based on TCP and not UDP. FTP is too big. > > SFTP - for disambiguation the "Simple File Transfer Protocol" or RFC 913 > - comes to mind which is between TFTP and FTP in terms of complexity and > runs over a single TCP port. It isn't entirely clear what you mean by a > "standard" tool - already installed or available off the shelf. I'd > imagine SFTP must be in the latter camp - probably a free download - but > I don't know any clients of the top of my head.
"standard" tool is something that can be installed. All software updates will be pushed from a central location, or maybe from a service engineer's laptop on-site, so it's acceptable to install the required tools on those machines. I just didn't want to write a special tool for this purpose. I'll check out SFTP, thanks.
Arlet Ottens <usenet+5@c-scape.nl> wrote in news:4d4bb079$0$81481
$e4fe514c@news.xs4all.nl:

> Hello, > > I'm working with some small embedded devices that need a software upgrade > capability through TCP/IP. I'm looking for a simple and lightweight > protocol to send some files. > > I'm aware of TFTP, which would be a candidate, but I'd rather have > something based on TCP and not UDP. FTP is too big. > > Ideally, it would be supported by some standard tool on the PC side. > > Does anybody have suggestion ?
How about Kermit: http://www.columbia.edu/kermit/index.html especially E-Kermit (embedded Kermit): http://www.columbia.edu/kermit/ek.html
On Fri, 04 Feb 2011 19:23:45 +0000, Ian Shef wrote:

>> I'm working with some small embedded devices that need a software >> upgrade capability through TCP/IP. I'm looking for a simple and >> lightweight protocol to send some files. >> >> I'm aware of TFTP, which would be a candidate, but I'd rather have >> something based on TCP and not UDP. FTP is too big. >> >> Ideally, it would be supported by some standard tool on the PC side. >> >> Does anybody have suggestion ? > > How about Kermit: http://www.columbia.edu/kermit/index.html > > especially E-Kermit (embedded Kermit): > > http://www.columbia.edu/kermit/ek.html
Does that still exist ? :) I already have TCP/IP, so all the packetizing, checksums, sliding windows and retry mechanisms add a lot of complexity without any benefit. I also have a fairly high latency connection, possibly including satellite modems on the other side of the world, so all the extra handshaking wouldn't be very good for throughput. For the same reason I don't like TFTP for this application.
On 2011-02-04, Arlet Ottens <usenet+5@c-scape.nl> wrote:
> On Fri, 04 Feb 2011 19:23:45 +0000, Ian Shef wrote: > >>> I'm working with some small embedded devices that need a software >>> upgrade capability through TCP/IP. I'm looking for a simple and >>> lightweight protocol to send some files. >>> >>> I'm aware of TFTP, which would be a candidate, but I'd rather have >>> something based on TCP and not UDP. FTP is too big. >>> >>> Ideally, it would be supported by some standard tool on the PC side. >>> >>> Does anybody have suggestion ? >> >> How about Kermit: http://www.columbia.edu/kermit/index.html >> >> especially E-Kermit (embedded Kermit): >> >> http://www.columbia.edu/kermit/ek.html > > Does that still exist ? :)
I use it every day. It's still being maintained, and the next major release (9.0) is due out any day now...
> > I already have TCP/IP, so all the packetizing, checksums, sliding windows > and retry mechanisms add a lot of complexity without any benefit.
I agree. If you got TCP, Kermit is pretty redundant.
> I also have a fairly high latency connection, possibly including > satellite modems on the other side of the world, so all the extra > handshaking wouldn't be very good for throughput. For the same reason > I don't like TFTP for this application.
TFTP through wide-area routed networks is likely to be a problem unless you've got control over all of the firewalls and make sure they're configured to allow TFTP traffic (by default, most aren't). A brain-dead "HTTP server" that presents a single page with an upload link contain a "POST" URL and the HTML allowing people to enter a filename or "browse" isn't that hard to do provide, and it'll be dead-simple to use and pretty much guranteed to work from any PC, any OS, regardless of what sort of network is between here and there. There are probably ways to do it that are a little easier to support on the client/device end, but all the ones I can think of will end up being a perpetual support hassle on the PC/human end. -- Grant Edwards grant.b.edwards Yow! My vaseline is at RUNNING... gmail.com
srl100 wrote:
>> Hello, >> >> I'm working with some small embedded devices that need a software upgrade > >> capability through TCP/IP. I'm looking for a simple and lightweight >> protocol to send some files. >> >> I'm aware of TFTP, which would be a candidate, but I'd rather have >> something based on TCP and not UDP. FTP is too big. >> >> Ideally, it would be supported by some standard tool on the PC side. >> >> Does anybody have suggestion ? >> > > HTTP POST/GET ?
Agreed. Trivial to implement.
On Feb 4, 2:55=A0pm, Grant Edwards <inva...@invalid.invalid> wrote:

> A brain-dead "HTTP server" that presents a single page with an upload > link contain a "POST" URL and the HTML allowing people to enter a
The other thing that he might try is to trigger the update via simply accessing the URL for the device, and then have the device pull the update from the net in general. I.e. a GET on dummy URL http://device.ip/pa= ssword triggers the device to serve up a dummy page that says "OK, doing it", then close that TCP connection and do its own GET on http://company.site/pa= th/upgrade.bin - that way the retries etc can be handled automatically at the device end. This might be a big advantage if the connection is slow and/or unreliable - I'm not sure about how to handle transfer resumption on a POST (suspect it isn't possible). A simple HTTP transaction (basically just GET) is really about the simplest TCP operation one can imagine anyway - extremely lightweight.