Re: [colorforth] A request for CF code & data for the CF block server

["pattenre" <pattenre@xxxxxxxxxxx>]

I  should have said the mac address.  Put mac address in  word list with
matched 32 kb block of memory while logged on.   accept only 3  sizes of udp
packets.

logon logof packet     If block number  and password that match  first cell
of block then put mac address and  block number  in wordlist   log off clear
mac and block number from word list for reuse.

block request packet   blocks  0-31 is   read from  associated mac
address/block number in wordlist.  if mac is not logged on then blocks 0-31
is public hello information. the remander of avalable blocks is published
blocks.

block write packet     blocks  0-31 is   writeable with  associated mac
memory address in wordlist  as block offset.

----- Original Message -----
From: "Tim Neitz" <tim@xxxxxxxxxxxxxx>
To: <colorforth@xxxxxxxxxxxxxxxxxx>
Sent: Tuesday, June 24, 2003 8:09 AM
Subject: Re: [colorforth] A request for CF code & data for the CF block
server


>
>
> On Sun, 22 Jun 2003, pattenre wrote:
>
> > I would setup a 32 block private read write block area for each user
with
> > the ability to publish finished blocks in read only public portion of
the
> > disk. Access to privete  areas is by absolute block number and first
word in
> > block if they don't match ignore user packets for 5 minutes. If they
match
> > shift remainder of block up 2 cells and write users IP address in cell 1
> > datetime in cell 2 after password in cell 0. Allow read write block
access
> > to blocks offset of 0 through 31 from IP address in list on block 0 .
This
> > will allow access control logging. Unused user area passwords could be
set
> > to "color"allowing immediate logon write access by anyone knowing the
> > default password. Giving your block number and password to others will
allow
> > teem development. When code on block is stable publish to associated
public
> > block.   Make "load"  relative on server  set absolute block with (
 n- ) "
> > parcel"
>
> Thanks for the good ideas, I will use this information when I am
> implementing the more robust access method. At the moment I'm looking for
> something really simple. I have a busy schedule, and would like something
to
> let others get a start for the next month or two. Hopefully after that I
> will have more time to spend on the access system. These ideas sound
> promising! But I'm afraid it's a bit much for the little time I have now.
> I will probably start with something closer to what I issued as a starting
> point for now. And later get to a system that is similar to what you have
> described here.
>
> Using the persons IP address for the read/write will require a fixed IP
for
> the developpers. Perhaps we could use the mac address instead? I know some
> of the developpers have limmited resources/access.
>
> With kind regards,
>
> Tim Neitz
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
> Main web page - http://www.colorforth.com


---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com