Re: LZ: Teleconferece
[Prev][Next][Index][Thread]
Micah/Richard Brodsky wrote:
>
> 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)
You do have a good point.. BUT! in this network (the one I was planing)
there actually would never need any sync'n! adn yer Idea is ok, I like
the idea of having NO server calc. but on teh other hand I woudl like
having a server calc cause then it would free up the work load for the
other calc's that are not Accelerated (mine is teh ONLY one in my entire
school district!!!). I say we build both programs and see which one
works better.
----/\=Clegg=/\----
Clegg@newrock.com
"Everything under the sun is in tune,
But the sun is eclipsed by the moon"
--Pink Floyd, DSOTM
'96
References: