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.

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

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.

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

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

Le 04/02/2011 16:30, Arlet Ottens a &eacute;crit :
> On Fri, 04 Feb 2011 15:25:17 +0100, Habib wrote:
>
>> Le 04/02/2011 08:53, Arlet Ottens a &eacute;crit :
>>> 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.
>
>> 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

On Fri, 04 Feb 2011 15:25:17 +0100, Habib wrote:

> Le 04/02/2011 08:53, Arlet Ottens a &eacute;crit :
>> 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.

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

Le 04/02/2011 08:53, Arlet Ottens a &eacute;crit :
> 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.
FTP is not so big as a client.
>
> Ideally, it would be supported by some standard tool on the PC side.
>
> Does anybody have suggestion ?