Quick Links: Proto-Toe ETOVP and other protocols Eranaer TOC-C TOC Server Other software EPTSL Project TkTemp Net::Server::Select::NonBlocking

Welcome to the TOE webpage. TOE is a software to project to implement a TOC server to which various TOC clients will connect to. Although our first need was to allow clients to connect to Toe, then Toe using the username and password supplied to it would initiate another connection to AOL's oscar server, acting as an oscar client, and forward all chat communications back and forth. Thus it would act as a sort of inter-protocol proxy, and would be both a server and client. However, given the fact that Oscar, despite the libfaim library, is very difficult implement, and is constantly being changed by AOL, the whole protocol being entirely undocumented, interacting with Oscar his complex task. Thus, we may find it easier to implement Toe as a standalone TOC server first, then add the ability to connect as a client to other protocol servers later.

- The Toe Server will act as a standalone TOC Server.

- Toe, using libfaim, will have a proxy mode, in where it will act as a TOC server to TOC clients, however, Toe will connect as a client to the Oscar server, and forward through all IM communications back and forth between the Oscar server and the TOC client. In this mode, the user name and password given to Toe by a client will be used by Toe to establish its client connection to Oscar. This will definitely be the case when we also support proxying to other protocols and chat systems, however, we need to do more research here, if the Toc clients use the same protocol for authorisation as the Oscar clients, we may somehow allow TOC clients to authenticate directly.

- As we stated above, we also hope to allow Toe to also connect to other chat systems on the behalf of clients. If we implement this feature, we may implement some additions to the TOC protocol. It may be useful for, in the connection between Toe and the TOC clients, for somehow some sort of indication to be transmitted to the client indicating which users belong to which network. No protocol level enhancement may be needed though, we may simply prepend an identifier to user names such as ICQ/43434, or YAH/Username, Toe will add these to the messages before there are sent out to the clients after they come from the service server. They will also be useful in messaging coming from the clients, since it will help Toe determine which system a message should be routed to. Toe will look at the extension, such as YAH/User, and in this case strip off the extension and send it on its way to Yahoo. We will have to investigate whether TOC can support the slashes, otherwise we might need other notation or to revert to a protocol level solution. We will also need to assure that the separator, such as a slash, are not used in AOL screen-names to avoid messy conflicts. If we make TOC protocol additions, the requirements will be that the additions do not interfere with older clients, older clients will still be able to use Toe (but maybe not the new features), and modified clients should work with older TOC servers, such as those AOL is using. We may need additional protocol enhancements and client modifications to allow for signing on onto multiple chat systems. Maybe the user would want to use their single TOC client to instruct Toe to use different usernames for different networks. That information will have to be sent by a protocol to the Toe server, hopefully encrypted.

Links

One of the main goals of the TOE server is to fully support AOLs TOC protocol. TOC is an excellent, feature rich, well designed protocol that has been tested and proven to provide a good quality exchange medium between chat clients and servers. TOC will be the most used protocol on TOE and we expect that many users will choose this protocol. However, to provide a little bit more chioce to the user, we have decided to support more than one protocol simply for a little variety. TOE will also support the ETOVP/ERPOUIMCS protocol which we have developed. ETOVP was originally created to be a very simple and easy protocol to implement (in relative to other protocols), to be totally text based and easily monitored and controlled from packet sniffers and telnet cleints. In fact, it is possible to use this protocol from a telnet cleint. Mesages are sent back and forth via one line single transmission commands, which are totally ASCII based. We have produced a protocol doc for ETOVP, and at some point in the future we will write a client.

However, despite ETOVP being included, we belive that most users willwant to use TOC instead, since it is amuch more efficient, well designed protocol. There are also a wide selection of clients. We belive that TOC is a very valuable protocol and very iomportant part of our server, more important than our own protocol.

In addition to ETOVP, we have also devloped a frame protocol called UFWP. All UFWP does is provide an underlaying frame container protocol which can lie under another protocol. Although ETOVP can be used directly over a TCP/IP connection, it can also be used atop UFWP, which in turn is based atop TCP/IP. UFWP wraps around the ETOVP commands and provides sequance numbers. It can also provide all a whole range of features of a packet level protocol, such as checksums and message sequance numbers, but we havent implemented this since in ETOVPs case we are implementing it atop TCP/IP which already provides these features. We may not implement UFWP right away, but it may be implemented in the future, ETOVP does not require it, it is an option. In addition, we are also planning on writing a protocol called EBCRP (ETOVP Based Chat Relay Protocol), which will be based on ETOVP but will be geared towards use on server to server relays. We are also working on ESCDP, or ETOVP Subset CHat Directory Protocol, whioch is contians the chat directory services found in ETOVP, and VMADP, Versatile Multipurpose Auhorixation and Direction Protocol, which is designed to be a facility to be used in future chat protocol suites which will allow a multi-connection suite of protocols to be used, possibly including an updated ETOVP protocols and other special purpose protocols for partticular purposes.

Downloading Protocol Documents

Some of the following documents do not use carriage returns for line wrapping, and thus we reccomend that you use a text reader which is capable of soft line wrapping with carriage returns when you open the document.

In the future, we are considering begining work on a few other interesting software projevts. Of course, we are always considfering new possibilities, so we may add to and expand the possibilies we will list here.

We are conidering working on a server, TOPS, or TOC to OSCAR Proxy Server. This serever, written in C or C++, will simply be a front end to OScar, it will take TOC connectiosn and forward all communicatiosn through to an Oscar server. DSIEP, Directory Server Implemtenting ESCDP Protocol, is a server which will implement chat room directory services using ESCDP. ADSBV, Authorixation and Direction Server Based upon the VMADP protocol, will be an authorizatoon server implementing VMADP. SORPS, Simple Oscar Relay Proxy Server, will simply be a proxy designed to allow users to easily use Oscar through a firewall. MTFRE, Multi-windowed Tac Front End, will be a Perl, or Tcl program that will simply serve as an easy to use and convenient front end for Tac, it will feature a seperate "window" for each room, with convienienting switching between each window. Hopefully, we will be able to write this in a scripting language and be able to use some sort of existing curses like capability. Tiling of the windows woll be more demanding, but we will look at the feasibility of that feature.

In order to provide a backend which will allow users using a TOC cleint to connect to OScar with thier, tik, tnt, tac, or other toc cleint, we will be working on a software called ITOBE. The big advantage of teh iTOBE concept is that it will work on any TOC Server without the need to support it in the TOC server itself.

ITOBE will connect to a TOC server as a normal cleint. USers on that TOC server may then send commands to ITOBE, within messages. These commands include telling ITOBE to open a cleint connection to an oscar server and login as a specific user. ITOBE will then send commands to the TOC user it recieves from the oscar, to teh TOC user by sending them in a special format as commands within TOC messages. The TOC user can then send commands within messages of its own. These commands will be defined in the MECLI specification. Part of the ITOBE will be a specification called MECLI, or Message Embedded Commands Language I. In addition, we will offer a software package called TPIML, Toc Plug-in Implementing MECLI Language. MECLI willhave two modes, teh first mode is the long handed mode which will include humand readbale commands for those who are not using a cleint which automatically handles the MECLI commands for the user. If the user is using a cleint that does the MECLI commands for the user, the cleint may then use an abbrievated form or MECLI, using single leter commands, and in addition when a TOC user first begins conversing with auser on a remote server through ITOBE, the remote users will be given a hex code, which could be used in place of the username. Both ITOBE and the MECLI aware cleint will keep a table of code to username associations.

In addition to offering commands within messages to aid in implementing a backend to another server, we are also considering creating commands within messages protocols for other purposes as well. Such may include implementations of our chat room directory protocols and auditorium features.

In addition to many of the new protocols mentioend above, we are also considering workmon several TOC addendums, these are simply specifications to implement additioanl TOC commands on TOC servers. Special care has been taken to allow a client to detect whether as best possible whether teh server supports the additions, our goal is to allow TOC servers which support the addendum to be back compataible with clients that do not, and vice versa.