Virtual Places Chat
Virtual Places Chat is software that uses the paradigm that any web page on the Internet is a chat room – or Virtual Place – if one or more people are viewing the page with the VPchat program. A web browser is an integral part of VPchat. When VPChat it is used there is a chat pane below the browser window in which the conversation text is displayed, below which is a box for entering text for the conversation. To the right of the browser window is a list of people in the room.
History
Virtual Places Chat software was developed by an Israeli company, Ubique, in the mid 1990s. Early customers included AOL and Excite. The chat software was popular with both services, though eventually AOL abandoned it in favor of other chat programs. A likely factor in this decision was the problem of controlling the content of avatars, which can be a problem for a family oriented service. The service remained and drew at its peak tens of thousands of concurrent chatters at Excite.
When Excite (later merged with @Home to become Excite@Home) crashed at the end of the dot com boom, a group of former Excite employees acquired the rights to use the software and launched vpchat.com. They planned to create a service they built upon the strengths of VP chat – the virtual places web page paradigm, avatars, tours, and games – while addressing the community management problems associated with the unrestricted graphics used in avatars. Their solution also addressed how to make chat services into a profitable business.
In 1995 AOL acquired Ubique, which was described by AOL as a client-server software architecture allowing people to virtually meet and interact.
In 1998 IBM acquired Ubique from AOL and from Ubique's founders; Virtual Places presence and instant messaging components became part of Sametime technology, an IBM solution for corporate communication and collaboration.
Subscription model
They created a subscription-based chat service. Chatters pay a nominal monthly fee to use the service. If a user repeatedly breaks community standards their service is terminated. For repeat trouble makers, attempts to create new accounts are no longer accepted. People need to identify themselves, e.g. with credit card billing information, so it is no longer possible to create dozens or hundreds of accounts.
The development of a subscription-based community management system was a major contribution to Virtual Places by Halsoft, the company behind vpchat.com. Halsoft has also released enhancements to the chat client and server, and new games and a web based game ladder and tournament management system.
Technical details
The VPchat protocol uses a TCP connection to the server on port 1533. To help circumvent problems if this port is not open in a firewall, FTP port 21 can be used instead. This is a per-client option.
There is also a separate buddy list/instant messenger client which can be used as a stand alone client or in conjunction with the chat client. There is a button in the chat client for launching the buddy list so it appears to be a sub window of the client, however it can remain running after the chat client closes and the user is connected to the chat server a second time through the buddy list.
Originally the buddy list was designed as a separate system, not necessarily related to chat rooms. Users signed in to the buddy list using an email address and password. The clients are now used at vpchat.com The system creates the buddy list name automatically by appending “@buddy” to the user’s chat name and they share the same password. This dual login works to allow the buddy list to exist with or without the chat client.
The buddy list client also supports a multi-user chat conference, similar to a chat room but without avatars. People participate in the conferences by invitation from the person who opens the conference. The rooms do not have names that appear in the public chat room list so uninvited users cannot find them and enter.
The chat protocol is proprietary, although Ubique at one time documented a subset and offered it as an Internet standard for buddy list and instant messaging. It was not adopted as a standard. In the late 1990s, Ubique was purchased by the Lotus division of IBM, and a second generation protocol was developed which is now in use by the Lotus Sametime instant messenger.
There is very low overhead associated with chat traffic. The avatars, up to 16K bytes each, are a potential source of performance problems. When a chatter first enters a room, which may contain many other chatters, he is sent all their avatars. This can be a major source of “lag,” which is addressed by sending the avatar′s asynchronous to the conversation text. A chatter will begin seeing the room conversation immediately, and he can participate in the conversation before any avatars are loaded. While avatars are loading the chatter will see “hour glass” graphics in place of peoples’ avatars. As the avatars are downloaded, interleaved with conversation, one by one the hour glasses convert to individual pictures. The time this takes varies depending on the connection.
Each chat connection from client to server is persistent. The TCP socket remains open for the duration of the chat session. This assists with implementing the idea of “presence” in the community, as the server knows who is connected and where they are chatting at all times. A disadvantage of persistent connections is the proliferation of server side connections as the number of chatters grows. Many chat systems deal with scale of connections by using non-persistent UDP based connections, at the expense of accurate, up-to-date presence information for all the chatters. The VPchat server deals with this by using a two layered system.
The developers observed that a large amount of processing overhead is consumed by the server managing all the connections, at the socket level. A layer of one or more multiplexors (muxes) is implemented, each of which does little more than manage a large group (several thousand per mux) of TCP sockets. The muxes make a periodic pass through all the sockets and gather all the incoming messages into a large bundle, or meta message, which is passed to the chat server. The server gathers the incoming bundles, breaks them apart and analyzes them, then builds new outgoing bundles which it sends to the muxes. The muxes then distribute the individual messages out through the client connections. In this architecture the server only has one TCP socket per mux, which is significantly less than the client connections. Thus a single server can easily scale up to a large number of client connections. New muxes can be added as needed. Given the performance of CPU technology of the late 1990s, Excite and Ubique estimated that a single VP server could manage a community up to about 100,000 chatters.
However to scale up to millions of users, as handled by chat systems such as Yahoo, MSN, or AOL, the single central server would have been a limitation. The Ubique and Excite developers were working on a multi-server enhancement to handle larger traffic, but the decline of Excite and the purchase of Ubique ended that effort. The Ubique engineers continued their efforts with Sametime, which now supports multiple central servers. For the much smaller level of traffic seen at vpchat.com, the single server technology is not an issue.
To ease the load on the central server, many auxiliary services are offloaded to specialized servers which can run on separate machines. For example, the user name and password authentication at login is offloaded to a server which works with a SQL database. The conversations of logged in chatters are not slowed while new chatters are authenticated. Also, management of presence – who is in which room – is maintained in a separate server, and searching for a user by name is offloaded to another server. There are also separate servers for managing buddy lists, game and tournament scoring, managing the chat auditoriums, and for miscellaneous statistics gathering.
The data management aspects of the chat service are handled with an SQL database. Individual chatters have a chat name and password. There is optional profile information which is saved on the server. Avatars and buddy lists are saved on the client side, and uploaded to a cache on the server when a chatter sign in. This works for scaling up the size of the system, but is a drawback when a chatter uses different computers as his avatars and buddy lists are not readily available.
The SQL database is also used for managing customer accounts. Users may purchase accounts that can have 2, 5, or 10 chat names associated with them. Any or all of the names can be used at the same time, for example family or friends can share an account. One person is responsible, however, for paying the monthly subscription fee.
The database assists community management by keeping track of privileges, penalties and warnings. Selected users can be given server privileges which include the ability to eject someone temporarily from a chat room, to “gag” the person for a period of time (i.e. prevent anything they type from being shown in the chat room), to prevent them from using an offensive avatar (i.e. their avatar is changed to an avatar of a baghead), or to eject them from the community entirely. Short of applying one of these penalties, a privileged user may officially “warn” another user about behavior. The use of penalties and warnings (who gave them out and who received them) is recorded so that the community managers can track behavior of troublemakers and also detect abuse of privileges. The system also lets individual users “ignore” the behavior of another user. The avatar and conversation from an ignored user cannot be seen by the ignoring user.
Users can also share files and engage in voice chat with each other. Files smaller than 64K bytes are shared through the TCP server connections, and larger files and voice connections are implemented as peer-to-peer messages between clients.