From: Adam Dunkels (adam_at_sics.se)
Date: 2001-10-17 13:51:22
Hi all! On Wednesday 17 October 2001 13:20, you wrote: > On Wed, Oct 17, 2001 at 01:36:51PM +0300, Marko Mäkelä wrote: > > Where is the content stored? In the main memory? > > Yes. uIP tries to be as portable as possible and so it doesn't use file > I/O. Maybe Adam can say more about this. The main reason for storing the pages in RAM instead of on some periphal storage device is that most devices that uIP is intended for doesn't really have any I/O capabilities other than the I/O port which runs TCP/IP. Think of embedded systems such as thermometers, sensors, etc. Think in terms of < 8k ROM and < 1k RAM. Another problem with using the disk for storing web pages is the latency this introduces. They way uIP works is that a request is handled immediately when it is received. Reading data from the disk drive would mean an order of magnitude increase in web server complexity. Basically, a "GET" request from the browser would cause a disk "LOAD BLOCK" command to be queued on the disk request queue. When the disk command is completed and the block has been read into memory, the block is transmitted by uIP and the "LOAD BLOCK" command for the next block is queued. This would also involve writing custom speed C64<->1541 transfer routines. I have been planning to implement such functionality, but it is not of highest priority. > > I think that the > > previous implementation (which was pure 6502 language, as far as I know) > > used 1541 disk storage. When I connected to that server's HTTP port with > > telnet, I could clearly see pauses in the HTML stream every 254 bytes. > > If you don't have any other stuff running, writing the web server in > assembly is not really necessary. The slowest link is the serial > connection. Even at 38400 bps (which is quite fast for a C64), only 4 bytes > are transmitted over the serial line each millisecond. This is not really > hard, even with a 1MHz 6502. > > One drawback is that the pages served are limited by main memory. But > serving larger pages or pictures over a serial link wouldn't be a good idea > anyway. A mixed scheme (reading objects from disk but caching them in > memory) would probably be a better idea. > > The nice thing about uIP is that it is portable. So there is a high chance > that improvements for one platform will also work for another, without the > usual porting efforts that are needed when using assembly. Indeed. Since uIP is written in C, people have been able to port it to several CPU architectures. It currently runs not only of the 6502, but also on the x86, 8051 and Hitachi H8S/2148. I have heard rumours of a Z80 port as well. /adam -- Adam Dunkels <adam_at_sics.se> http://www.sics.se/~adam ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo_at_musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2001-12-14 22:05:43 CET