Looking for simple file transfer

HTTP POST/GET ?

--------------------------------------- Posted through

When you say "standard tool on the PC side", do you mean "standard on windows"? There are lots of options that are standard on Linux - the very simplest being to use netcat, with alternatives including rcp, scp, and webdav, or weirder setups like making a network-accessible tty (i.e., a remote serial port).

But if you are talking about windows, you are very limited. If you don't like FTP because of its size, you will definitely not like SMBFS/CIFS. That leaves you HTTP. You can use webdav so that your system is accessible like a remote file system, but beware that windows doesn't follow the standards, and different versions of windows break the rules in different ways. The other poster's suggestion of HTTP POST is probably your best bet - make an embedded web server with a form and a "file upload" button.

Ideally, it should be used both on Linux and Windows. I use Linux for development, but customer uses Windows. However, (cygwin-based) command line tools are acceptable, so that leaves plenty of options, I think.

I'm starting to like the idea of using HTTP. I considered it before, and thought it would be too big, but a very stripped down server would probably be of comparable size to alternatives, with the big advantage that a browser is already installed, and really easy to use. It's also very flexible, so I could add some more pages in the future for remote diagnostics/control.

I'm woefully ignorant of the software side of things, but could Datalight's Sockets work? Runs from a DOS level;

fyi

de

...

oops, try this;

That looks like a generic TCP/IP socket interface. I already have TCP/IP on my embedded system, but I was looking for a simple application layer on top of that to send some files across.

I think I'll go ahead with the HTTP GET/POST protocol, as suggested by others.

Le 04/02/2011 08:53, Arlet Ottens a écrit :

FTP is not so big as a client.

The client isn't the problem. It's the server, which would run on the embedded platform. Also, FTP is a messy protocol. The separate data/ control sockets are just annoying, especially with NAT and/or firewalls in the way.

Consider the amount of work to implement a TCP/IP server (a descent one of course) servicing multiple clients at a time ... i think it's possible via inetd although i've never been in the situation of doing what you're are trying to do.

Habib

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 wrote in news:4d4bb079$0$81481 $ snipped-for-privacy@news.xsall.nl:

How about Kermit:

especially E-Kermit (embedded Kermit):

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.

I use it every day. It's still being maintained, and the next major release (9.0) is due out any day now...

I agree. If you got TCP, Kermit is pretty redundant.

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.

Agreed. Trivial to implement.

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

- 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.