Re: LZ: Teleconferece


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

Re: LZ: Teleconferece



At 04:23 AM 7/16/1996 -0400, you wrote:
>Min Idzelis wrote:
>> 
>> PROTOCOL IDEA:
>> ok... this is something that would be VERY simple. Since data comming from
>> the port is 1s and 0s, we can send text in morse code. 1s would be dots, and
>> 0s will be dashes. Everybody who wants to chat connects at the same
>> frequency. The software for the TI would do this. If the calculator is
>> receiving, it would not transmit. So it won't interfere with the
>> transmittion. If a person tries to transmit, it would be put in a "cache"
>> and transmitted when  the line is free. And that's all you need. To make
>> people on the link more distinguashable, you could make the software prefix
>> the name of the calc in front of every transmittion. All of this would be in
>> morse code. If 1s and 0s won't work, (because of timming difficulties), you
>> could make a dot be 11 and a dash be 01, and 00 would be the "line clear"
>> signal. So other people can broadcast when there is a stead 00. Does this
>> make sence?? It would be easy to impliment, like only a couple thousand
>> bytes, i imagine less than 6000???? I think.
>
>If the calculator is receving it would not transmit?  That could be a
problem.  
>Imagine this: Two ti-85s, each waiting till they're done receving, send at
the same 
>time. Result: instant crapola.  This is a huge program with most networks,
especially 
>ethernet.  However, this is not a bad thing.  On ethernet, if a packet is
garbled 
>(collides), the sender just waits a random amount of time before resending.
This 


Well, like you suggested, we can make it wait a random amount of time,
between .5-2secounds should do it. Then the "two ti-85s, each waiting til
they're done receiving" would not send at the same time... one would send
first, and since the other calc is recieving now, it would wait till that
calculator is done transmitting. This would be simple, but would introduce
time-lags, and make conversation kinda choppy. But for cheating, it should
work nicely. 


>might not be practical with the TI-85, I don't know.  Another solution is a
token 
>ring.  There is only one token per network, which allows a computer to
send.  This 
>token is then passed around.  Since there is only one system transmitting
at a time, 
>there are no collides.  The only part of this that i can't figure is how to
originally 


well, you can always talk before hand in real life with the people you want
to talk with over the tinet and determine who will be the initializer. 


>initiallize the network.  Probably the system listens for traffic on a net,
and if it 
>cant find any, it initallizes the net and gives it an id.  Probably every
few loops it 
>checks to see if any other/new systems are online, one id after another,
and fixes the 
>loop accordingly.
>
>Right now visions of a two-layer stack are drifting through my head
(application and 
>physical layer protocols, suitiable for networked games chat, or anything
elseyou can 
>think of, in a standardized routine library for zshell 4.5) that way, you'd
have a 
>standard link system, and all you'd have to worry about is getting your
data into the 
>physical protocol and out the door (or port 7).
>


I think if you want to play a game over a network, it would be VERY
complicated, and the transmittion would have to be DUPLEX, that is transmit
and recieve at the same time. But if we could make a standardized routine
for zshell 4.5, it would BE GREAT!! 


>I think i'd better get some more sleep.
>-- 
>  _____         _        ____              __    
> / ___/______ _(_)__ _  / __/_ _  __ _____/ /__ _
>/ /__/ __/ _ `/ / _ `/ _\ \/  ' \/ // / _  / _ `/
>\___/_/  \_,_/_/\_, / /___/_/_/_/\_,_/\_,_/\_,_/ 
>               /___/                             
>aa023@detroit.freenet.org
>


References: