cURL has no problem with ftp:// it handles LOTS of protocols
>________________________________
>From: Michael B. Brutman <mbbrut...@brutman.com>
>To: freedos-devel@lists.sourceforge.net
>Sent: Wednesday, July 6, 2011 4:32 PM
>Subject: Re: [Freedos-devel] watcom tcp
>
>
> On 7/6/2011 6:02 PM, Bernd Blaauw wrote:
>
>ftp://ftp.xs4all.nl/pub/test/10mb.bin :
1) 2.0 to 2.5MByte/second ( around 20Mbit/s, 25Mbit ISP subscription)
2) N/A , WGET not working
3) 500Kbyte/second ( around 4Mbit/s)
>mTCP FTP compares poorly to the native stack and FireFox there, but
FTP is working in a very limited environment:
>
> * The TCP/IP socket receive buffer is tiny compared to the native
> network stack
> * You are doing filesystem writes 8KB at a time
> * You have a small virtualization penalty
> * The packet interface wasn't designed for high performance; every
> incoming packet requires a hardware interrupt and two software interrupts
But for older machines, it is more than adequate. I'll try a few tests here -
I also test under VMware, VirtualBox, and DOSBox but I never thought to compare
the performance to the native TCP/IP stack.
>
>Did you set the MTU size to 1500 in the configuration file? If you
did not, that will dramatically improve the speed.
>
>
>Trying to get FTP.EXE working with WGET syntax is funny.
Limitation: servername has "//" prepended to it which ftp.exe doesn't like.
>That funny URI syntax was grafted on. What exact URI are you
using? Are you adding "ftp://"; or just "//" ?
>
>
>
>Bug: DHCP.EXE doesn't start on newline, ruining IPADDRESS parameter
(my MTCP.CFG has PACKETINT 0x60 but lacked CR/LF somehow).
>Can you explain this in more detail? If you were missing a proper
CR/LF at the end of a line then the C runtime would not have
recognized the start of the next line, and that line would be
effectively lost. This happens if you use an editor that doesn't
use the CR/LF convention. (I often make this mistake when using VI
under Cygwin.)
>
>I could recognize both CR/LF and LF in the parsing code to improve
things when you are in a mixed environment. But all of the code
that reads the configuration file would have to change too, not just
DHCP. That really has the flavor of a user error.
>
>
>
>Request:
* FTP accepting "//" in front of a servername
* DHCP starting MTCP.CFG writes on a newline
* DHCP: different errorlevels for various situations instead of
errorlevel 1 on all errors? aka "how to determine if packet driver still
needs to be loaded" Bernd
>For the first request I think that I have to look for either "ftp://"; or just
>"//" to be correct. The second request might be considered a user error. And
>for the third I will definitely put that on the todo list; the error messages
>already indicate if the packet driver is not loaded but I can set errorlevel
>too.
>
>
>Mike
>
>
>------------------------------------------------------------------------------
>All of the data generated in your IT infrastructure is seriously valuable.
>Why? It contains a definitive record of application performance, security
>threats, fraudulent activity, and more. Splunk takes this data and makes
>sense of it. IT sense. And common sense.
>http://p.sf.net/sfu/splunk-d2d-c2
>_______________________________________________
>Freedos-devel mailing list
>Freedos-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
>------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
