Editing Virtual1's Hotline Server Protocol Guide (section)

===Chapter 3: TRANSACTIONS===

Transaction are sent under the following format:
 • header
   • short (transaction class)  0=info/request, 1=reply
   • short (transaction ID number)  server replies are always zero
   • long (task number)
   • long (error code)  valid if this is a reply, 0=ok, 1=err
   • long (length of data block)
   • long (length of data block) yes, again.  I don't know why.
 • data
   • short (number of objects in transaction)
   • objects  can be one, many, or none

It would be wise to assume that objects can be passed in IN ANY ORDER. The other
Hotline Client sockets I have seen thus far will crumble to dust if Hinks changes
the order of the objects, and I just bet his clients and servers are designed to
handle this. BEWARE.

Transaction IDs, classes, types, names, and objects:
 ID# Cls Init    Type     Name                 Object(s)                          
 101  0  Client  request  GetNews              (no objects passed)
   0  1  Server  reply    GetNews              message
 102  0  Server  info     NewPost              message
 103  0  Client  request  PostNews             message
 104  0  Server  info     Broadcast            message
 104  0  Server  info     Error                parameter,message
 104  0  Server  info     PrivateMessage       socket,nick,message(,banflag)
 105  0  Client  info     SendChat             message(,chatwindow)(,parameter)
 106  0  Server  info     RelayChat            message(,chatwindow)
 107  0  Client  request  Login                login,password,nick,icon
 108  0  Client  request  SendPM               socket,message(,banflag)(,quote)
 109  0  Server  info     Agreement            message
 110  0  Client  request  Kick                 socket(,ban)
 111  0  Server  info     Disconnected         message
 112  0  Client  request  CreatePchatWith      socket
   0  1  Server  reply    CreatePchatWith      chatwindow,socket,icon,status,nick
 113  0  Server  info     InvitedToPchat       chatwindow,socket,nick
 113  0  Client  info     AddToPchat           socket,chatwindow
 114  0  Client  Info     RejectPchat          chatwindow
 115  0  Client  request  RequestJoinPchat     chatwindow
   0  1  Server  reply    JoiningPchat         userlistentry(,userlistentry,...)(,subject)
 116  0  Client  Info     LeavingPchat         chatwindow
 117  0  Server  Info     JoinedPchat          chatwindow,socket,icon,status,nick
 118  0  Server  Info     LeftPchat            chatwindow,socket
 119  0  Server  Info     ChangedSubject       chatwindow,subject
 120  0  Client  Request  RequestChangeSubject chatwindow,subject
 200  0  Client  request  FolderList           (path)
   0  1  Server  reply    FolderList           {fileentry}
 201 (unused)
 202  0  Client  request  Download             filename(,path)(,resumeinfo)
   0  1  Server  reply    Download             xfersize,xferID
 203  0  Client  request  Upload               filename,xfersize(,path),(resumeflag)
   0  1  Server  reply    Upload               xferid(,resumeinfo)
 204  0  Client  request  MoveToTrash          filename(,path)
 205  0  Client  request  CreateFolder         filename(,path)
 206  0  Client  request  GetFileInfo          filename(,path)
   0  1  Server  reply    GetFileInfo          infotype,infolongtype,infocreator,filename,
                                               infocreated,infomodified,infosize(,comment)
 207  0  Client  request  SetFileInfo          filename(,path),(newfilename OR comment)
 208  0  Client  request  MoveFile             filename(,path)(,targetpath)
 209  0  Client  request  MakeAlias            filename(,path)(,targetpath)
 300  0  Client  request  GetUserList          (no objects passed)
   0  0  Server  reply    GetUserList          {userlistentry}
 301  0  Server  info     UserChange           socket,icon,nick(,status)
 302  0  Server  info     UserLeave            socket
 303  0  Client  request  GetUserInfo          socket
   0  1  Server  reply    GetUserInfo          message(,nick)
 304  0  Client  info     ChangeNickIcon       icon,nick
 350  0  Client  request  CreateUser           login,password,nick,privs
 351  0  Client  request  DeleteUser           login
 352  0  Client  request  OpenUser             login (NOT ENCODED)
   0  1  Server  reply    OpenUser             login,password,privs(,nick)
 353  0  Client  request  ModifyUser           nick,login,password,privs
 354  0  Server  info     Userlist             {userlistentry}
 355 broadcast
 370  0  Client  request  NewsDirlist          (newsdir)
      1  Server  reply    NewsDirList          {newsfolderitem}
 371  0  Client  request  NewsCatList          (newsdir)
      1  Server  reply    NewsCatList          (newsgroup)
 380  0  Client  request  DeleteNewsDirCat     newspath (kills categories and dirs)
 381  0  Client  request  MakeNewsDir          newspath,filename
 382  0  Client  request  MakeCategory         newspath,category
 400  0  Client  request  GetThread            newspath,threadid,newstype
      1  Server  reply    GetThread            newsdata,prevthread,nextthread,newssubject,
                                               author,newstype,newsdate
 410  0  Client  request  PostThread           newspath,threadid,newssubject,unknown 334,newstype,newsdata,
      1  Server  reply    PostThread           newspath,threadid,newssubject,unknown 334,newstype,newsdata,
 411  0  Client  request  DeleteThread         newspath,threadid


Transactions dealing with files always include the filename. If the path is not included, root folder can be assumed. If the file is being moved or aliased, targetpath may also be included. If not, root is assumed as the target.

Transaction #105 (SendChat) is chat. When sent with a parameter of 1, it becomes an emote.
Server reply to #352 always returns string(ctrl-G) as password. #353 must send a password string (chr(0)) if password was not changed. Returning string(ctrl-G) will result in that being the user's new password!

Unless otherwise specified, a successful task reply will have an
error code of 0 and no objects. Unsuccessful tasks will
reply with an error code of 1 and the errormsg object.

Server transaction #104 "Error" is used for when client sends a non-request that fails, such as trying to send public chat when they don't have chat privs. (probably a screw-up by Hinks, he should have made ALL transactions generate a reply, IMHO)

Note: reply to #303 (get info) will be missing the Nick object if you're getting info on a "ghost". (HotSocket will return "" - the HL client returns "Unnamed User") The HL client will not allow a user to set their name to blank. (spaces are OK tho)


Note: a Task is a reply to a request. The object(s) included in the Task
are dependent on what the request was. The Task can be matched back to
its request by using the task number portion of the header. It's probably
possible to reuse task numbers, but don't re-issue a task number in a
request until the current instance of that task number has been replied to!
I have noticed that while the client can create tasks, the server cannot.
This makes sense, because a server would eventually crash or eat up all
available memory if it had to remember tasks until complete, assuming it
was up a week or so and had clients dropping. (leaving tasks in the air)