Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #24953

Re: SMB/CIFS for uTasker/Coldfire?

Show all headers | View raw

On 09/09/16 13:05, Don Y wrote:
> On 9/9/2016 3:20 AM, David Brown wrote:
>>>> For TFTP, it is simpler if you stick to 512 byte data blocks (plus
>>>> the 4
>>>> byte TFTP header).  If you are looking for optimal transfer speed of
>>>> large files, it is worth negotiating bigger block sizes (assuming both
>>>> sides support it), but for 4.5 KB it is easier just to send 9 packets.
>>>> You also don't want to deal with big UDP packets when your
>>>> microcontroller has little ram - why mess about trying to put together
>>>> separate Ethernet frames into a single UDP packet when you can have the
>>>> packet entirely within one frame, and use it directly without any
>>>> copying?
>>>
>>> A smarter move is to negotiate a larger window size.  So, the "next"
>>> transfer can begin before your acknowledgement of the earlier one
>>> has been received.  But, you have to 'remember more' to implement this
>>> (on server and client).
>>
>> UDP does not have a "window size" - it has a packet reassembly buffer
>> size.  And with TFTP, your next transfer /cannot/ begin before the
>> acknowledge of the previous packet is sent - that is fundamental to the
>> TFTP protocol.  It is a simple query-response protocol.
> 
> No.  Later RFC's enhanced the protocol to allow for the sender and
> receiver to negotiate a number of outstanding yet-to-be-ACKed
> packets.
> 

Ah, okay.  I have only used TFTP in its original /trivial/ version.  I
know you can negotiate certain aspects, such as block size (and
apparently the number of outstanding blocks), but I did not bother with
such "features".  That would completely miss the point, as far as I can
see.  And when an 200 KB update takes a second or so, including flash
erasing and programming, there's little need to complicate things.

> So, if you specify a window size of 8 (packets), the sender can
> send up to 8 packets (the size of each can also separately be
> negotiated) before requiring an ACK from the receiver.  An ACk
> indicates the block number that is being acknowledged.  It
> *implies* acknowledgement of all consecutive block numbers
> up to and including the block in question.
> 
> By way of example, a sender can push packets 1, then 2, then 3, then
> 4, then 5, then 6, 7, 8 onto the wire BEFORE waiting for an
> acknowledgement (in the case of a window size of 8).  If it receives
> an "ACK(8)", then it knows packets 1-8 have been successfully received
> and acknowledged.

For high throughput, especially over higher latency routes, I can see
this making sense.  But if I needed something like that I would be
tempted to make my own simple protocol over TCP and let the TCP stack
handle all the details here (as well as making firewall traversal much
easier).
> 
>>> But, for 4K files, its a moot point.
>>
>> Agreed.
>>
>>> The problem (potentially) comes when you later decide to leverage
>>> this existing code to address some OTHER need -- that doesn't
>>> suffer from the same assumptions.
>>
>> That may be true.  TFTP is designed to be simple and low overhead, but
>> not high speed, flexible, or suitable for larger networks.
>>
>> If the requirements change, you have to look at something else.
> 
> Or, understand the impact on the protocol.  As I said (snipped),
> just because you plug device X and Y into *a* network doesn't mean
> the protocol will behave the same as if plugged into the same
> *switch*, etc.
> 
> Note that you should actively shape UDP traffic to "be a good
> network citizen".   Just because you *can* issue requests/packets/ACKs
> at a particular rate doesn't mean you *should* do so!
> 
> And, while it is probably NOT the case in RY's application, you
> have to remember that the receiver and transmitter may have
> other uses WHILE you are running this protocol.
> 

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

SMB/CIFS for uTasker/Coldfire? Randy Yates <yates@digitalsignallabs.com> - 2016-09-06 12:18 -0400
  Re: SMB/CIFS for uTasker/Coldfire? Randy Yates <yates@digitalsignallabs.com> - 2016-09-06 18:13 -0400
    Re: SMB/CIFS for uTasker/Coldfire? Dimiter_Popoff <dp@tgi-sci.com> - 2016-09-07 01:58 +0300
    Re: SMB/CIFS for uTasker/Coldfire? David Brown <david.brown@hesbynett.no> - 2016-09-07 14:33 +0200
      Re: SMB/CIFS for uTasker/Coldfire? Dimiter_Popoff <dp@tgi-sci.com> - 2016-09-07 16:44 +0300
        Re: SMB/CIFS for uTasker/Coldfire? Randy Yates <yates@digitalsignallabs.com> - 2016-09-07 22:10 -0400
          Re: SMB/CIFS for uTasker/Coldfire? David Brown <david.brown@hesbynett.no> - 2016-09-08 08:54 +0200
            Re: SMB/CIFS for uTasker/Coldfire? Randy Yates <yates@digitalsignallabs.com> - 2016-09-08 12:10 -0400
          Re: SMB/CIFS for uTasker/Coldfire? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2016-09-08 09:54 +0300
            Re: SMB/CIFS for uTasker/Coldfire? Randy Yates <yates@digitalsignallabs.com> - 2016-09-08 12:08 -0400
          Re: SMB/CIFS for uTasker/Coldfire? Don Y <blockedofcourse@foo.invalid> - 2016-09-08 01:08 -0700
            Re: SMB/CIFS for uTasker/Coldfire? Randy Yates <yates@digitalsignallabs.com> - 2016-09-08 11:59 -0400
              Re: SMB/CIFS for uTasker/Coldfire? Don Y <blockedofcourse@foo.invalid> - 2016-09-08 10:02 -0700
              Re: SMB/CIFS for uTasker/Coldfire? George Neuner <gneuner2@comcast.net> - 2016-09-08 13:23 -0400
                Re: SMB/CIFS for uTasker/Coldfire? Don Y <blockedofcourse@foo.invalid> - 2016-09-08 14:28 -0700
                Re: SMB/CIFS for uTasker/Coldfire? David Brown <david.brown@hesbynett.no> - 2016-09-09 09:03 +0200
                Re: SMB/CIFS for uTasker/Coldfire? Don Y <blockedofcourse@foo.invalid> - 2016-09-09 01:05 -0700
                Re: SMB/CIFS for uTasker/Coldfire? David Brown <david.brown@hesbynett.no> - 2016-09-09 12:20 +0200
                Re: SMB/CIFS for uTasker/Coldfire? Don Y <blockedofcourse@foo.invalid> - 2016-09-09 04:05 -0700
                Re: SMB/CIFS for uTasker/Coldfire? David Brown <david.brown@hesbynett.no> - 2016-09-09 14:01 +0200
                Re: SMB/CIFS for uTasker/Coldfire? Don Y <blockedofcourse@foo.invalid> - 2016-09-09 10:18 -0700
                Re: SMB/CIFS for uTasker/Coldfire? "mjbcswitzerland" <62911@EmbeddedRelated> - 2016-10-03 06:23 -0500
                Re: SMB/CIFS for uTasker/Coldfire? upsidedown@downunder.com - 2016-09-09 12:39 +0300

csiph-web