This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problems when aborting tftp transfers


On Tue, Aug 03, 2004 at 08:40:46AM +0200, ?yvind Harboe wrote:
> I haven't got the setup available right now, but I think I remember the steps 
> to reproduce a bit better:
> 
> 1. start tftp transfer
> 2. abort tftp transfer
> 3. at this point the new tftp server thread is waiting for timeout on
> #1
> 4. start new tftp transfer
> 5. wait a bit(but not long enough for tftp transfer to start).
> 6. abort tftp transfer
> 7. at this point the tftp server is stuck in the main loop timing out on
> WRQ requests. Each WRQ request requires a tftpd_write_file() to time out, so
> this takes a loooong time.

This now make sense. It is the starting of the new connection before
the old one times out that causes the delay. Since the system is
single threaded it has two choices when the new connection request
arrives. The current implementation simply buffers the request until
later. The alternative implementation would be to discard the request
and let the client retry. Both implementations are probably correct
but have pros and cons. All these aborted connections is a corner case
that should not happen very often so i would not worry about it.

Having said that, i think the real solution is to teach your users to
have some patients and not abort the connections....

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]