RE: LZ: Teleconferece

[Prev][Next][Index][Thread]

RE: LZ: Teleconferece

   Why use a server? Why not just set up a calc as an initiator, and one as a 
client just to start it? The system could use packets, each with a unique 
'starter byte' for each type and then the netID (or proposed one) next. The 
initiator and client would run the ZShell program. Each calc would choose a 
netname and netID. The initiator's user would choose 0 for the netID and the 
client would then automatically choose 1 (after the next step). The initiator 
would open a 1 user 0 server network. The client would then wait for an 'end 
of cycle packet' to be transmitted, and in the short delay that followed (like 
maybe 1/10 second), it would send a login packet, containing it's name. The 
login packet would be as minimal as possible to reduce conflicts. The 
initiator would send a login acknowledgment packet (that way the initiator 
would be able to blacklist users, but not have any extra work to do that would 
make it miss things posted) containing the new client's netID and immediately 
terminate the delay. It would then send its 'data packet,' containing any data 
it wanted or was requested to send, any requests, any rerequests (if something 
was lost due to interference), and a 'go signal' at the end. The calculator 
with the next highest netID would respond with a 'go acknowledgment packet' 
and then it's 'data packet.' In the event of interference, the 'go 
acknowledgment packet' would not be sent, and the previous calculator would 
resend its 'data packet.' This process would repeat.


Additional notes:
1) A calculator would logoff by sending a special 'subpacket' in its 'data 
packet.'
2) If a login failed (interference or blacklisting), the client would either 
wait for the cycle to complete again and retry, or it would forget about it.
3) 'Error notification packets' could also be implemented in the event of a 
problem in the place of a data or acknowledgment packet, optionally followed 
by the displaced packet.
4) In the event of total confusion during the login delay (from multiple users 
logging in at once), the initiator would wait for maybe 1 half of a second and 
send an 'error notification packet,' followed by its 'data packet.'
5) Each packet could optionally be followed by a checksum to prevent the 
consequences of undetected interference.
6) Each submission of data in the 'data packet' would have an/some address 
netID(s) or be global and the receivers would store it then, saving 'error 
notification packets' and rerequests for their turn to send a 'data packet.'
7) Each calculator would keep its own list of netIDs and netnames. All 
calculators would pay attention to the 'login acknowledgment packet' and take 
down the new user's info.
8) This system could be implemented with interrupts, necessitating a short 
period of resending the 'starter byte' (Only by the clients with interrupt 
using calcs next. This could conceivably be too hard to implement, so when 
interrupts are allowed, all clients would have to do this) with intervening 
special bytes that would be illegal as a 'starter byte' (such as all 1s). The 
system could also be implemented with a client program system, or both. Use of 
interrupts would slow the whole network, though.
9) If a client would not respond to its 'go signal,' a specified number of 
times, the frustrated sender would automatically send a 'kickoff signal' and 
every calculator would remove the dead client from their lists. The same thing 
would occur by the hands of the second of two of the clients if the first 
would not finish its data packet in a specified amount of idle time.


Cool advantages:
1) Interference would not be a problem.
2) NO SYNCHRONIZING NECESSARY!!!
3) No calculator would have to be constantly managing the servers duties and 
not be workable as a client. The initiator would be like everyone else, other 
than it would have to acknowledge logins and store the 'blacklist,' but 
nothing would happen on the network while it was doing it's tiny chore.
4) You could have a popup menu available at all times, and it could be used to 
request files, open a chat session, send files, send email, receive email, or 
to return to network use as a full time thing.


Minor disadvantages:
1) It could end up to be slightly slower than the alternative.
2) If a person had the patience, they could rewrite the client program and be 
able to do annoying things to the other clients, but blacklisting could solve 
that (mostly). However, one unavoidable thing with any radio network is that 
someone could just broadcast a heck of a lot of interference and ruin the net.


I think that I've thought this out pretty completely. Please excuse any 
punctuation or spelling errors. If you would like to comment to me, send mail 
directly to my account. I WILL BE AWAY FOR 3 WEEKS, starting tomorrow, back 
for a weekend, and away again.


Have fun with this protocol! (Call it Micah's Protocol, if you like. PLEASE;)


<HUGE TRUE BOAST>
By the way, I program QuickBASIC, Visual Basic, QuickC, TASM Z80 for ZShell, 
TI-BASIC, I used to know Applesoft Basic and Apple Pascal, and I'm learning 
Visual C++ and Jet 3.0 DAO for Visual Basic.
</HUGE TRUE BOAST>


--MZB (micahbro@msn.com)




----------
From: 	owner-list-zshell@defiant.rbk.sollentuna.se on behalf of Clegg
Sent: 	Saturday, July 13, 1996 9:29 PM
To: 	list-zshell@defiant.rbk.sollentuna.se
Subject: 	Re: LZ: Teleconferece




Eric P. Anderson wrote:
> 


> I think that we need to create some sort of "y adapter" for the link port so
> that we can plug multiple things in at once (i.e. the rtlink and the
> speaker).  Maybe even a daisy chain type of thing, but I don't know if that
> would be possible.  I think that the IRC thing would be much more difficult
> to implement.
> 
> Any futher input, anyone?
> 
> ************************************************************
> *  Eric P. Anderson                     "Who is General    *
> *  crusader@mo.net                      Failure and why    *
> *  http://walden.mo.net/~crusader/      is he reading      *
> *  Finger for PGP public key.           drive C?"          *
> *  Fprint:3E 3C 52 A2 C1 3F 61 B5 71 7F 10 F1 09 B4 D4 D7  *
> *  This is a public notice that all unsolicited and/or     *
> *  commercial emailers will be charged an archival and     *
> *  downloading fee of U.S. $500.  Emailing me signifies    *
> *  agreement to these terms.                               *
> *  "The price of freedom is eternal vigilance." -Jefferson *
> ************************************************************




I have been thining of it...
and I dont know how to program in ASM, but I do in Basic.  SO I have some 
understanding 
of programing, adn from what I knwo it wouldent be that hard. that is to build 
a program 
to run the Teleconf.  The sync'n would take soem work but wouldent be that 
hard to 
overcome. I also am a future Network Engineer so I know how a network runs.  
and if you 
could get the program to "Listen" to what is happening on the channel you 
could sync the 
data quite easly. adn then you could also have the "server calc" listen to 
hear if ther 
are any Additional calc joining. cause on the "workstation" calcs when you 
initalize the 
 teleconf program they will need to wait and listen first to hear if there is 
a "All 
clear" signal sent out by the server (which it would ever couple times a sec 
adn woudl 
alow time for additional calcs to login.) so that teh workstation calcs know 
there is no 
data being exchanged. (this would prevent talking over and grabling data)  for 
this 
system to work teh server would need to send all commands out. meaning: that 
all the 
workstation cals would now accept info from ANY calc but the server.(so teh 
server would 
have a data paket that says "this form teh server" and all the other calcs 
would listen.


Each calc would have its own name. that will be transmited durring the login.  
adn that 
is how the server calc will control all the data.  Since this si a VERY data 
intensive 
adn computational intensive program (server) teh person using the server calc 
MUST be 
accelerated. all the other calcs can run accelerated or not.  all they will be 
doing is 
listening and recieving.


On teh workstation side:
You will haev a list on the screen that says whos all on the network, adn then 
you could 
send private messages to one adn another or groups. or just everyone. BUT the 
person 
with the server can see every message.


On the Server side:
Ther server calc will have the power to lock people out of the group or not 
allow them 
to hear some stuff.


Static, adn interfearence.:
This is a problem.. btu actually its not. as I sit here typing this I am 
thinking...


The workstation calcs will nto be affected by interfearence in anyway but they 
might 
miss some info.  The static would not screw with teh sync rate because  all 
the 
workstations do is.. sit there and listen for a message from the server. if it 
is not 
properly transmited or garbled the WC (workstation clac) will just ignore it. 
same with 
the SC(server calc) and if you are tansmiting a message from a WC or the SC 
the calc 
will transmit a sorta init code to tell teh calc "I am ready to send data are 
you 
ready?" adn it will listen for a answer.. if there is static adn it is lost in 
it.. well 
 it resends it latter(couple times a second).


it si a pretty passive RF network.  these are my ideas, adn if I coupld 
program in ASM 
goo di sure as hell would and give it to everyone!


If you decide to take this on please E-mail me so I can give you soem more 
details. adn 
there will need to be 2 versions of the program 1 server and 1 workstation. or 
you could 
get REAL nifty and have a prompt when you start the program if you want it to 
be the 
server or a WS. (intigrate both programs into 1)


Well Please tell me what you think. 
                           ----/\=Clegg=/\----
                            Clegg@newrock.com
                  "Everything under the sun is in tune,
                   But the sun is eclipsed by the moon"
                                      --Pink Floyd, DSOTM
                    '96