News
About
Features
Screenshots
FAQ
Mailing list
Contact
Installation
IRC usage
Server connects
DCC sends
Logging
Roadmap
Download
Config parser
Visions & ideas
IRC usage
MetalServe joins and listens on the configured IRC channels for one of the following commands (replace "<nickname>" with whatever Nickname you configured):
| Command | Action |
|---|---|
| @<nickname> | requests the file list |
| !<nickname> <file> | requests the specified file |
| @<nickname>-remove [<file>] | removes the specified file or all files from the queue |
| @<nickname>-que | returns information on the queue status |
| @<nickname>-hint <file> <message> | give the sysop a hint about the specified file (see below) |
| @find <string> | have the servers search their file lists locally for the specified string |
| @locator <string> |
When the user requests a file (including the file list) and a free send slot is available, he will be sent the file immediately. Otherwise he will be put into a waiting queue.
The number of send slots, like the queue length, is configurable and determines how many DCC SENDs MetalServe will perform at the same time (see DCC sends for more information). A user can obtain information about his queue position and the estimated remaining time using @<nickname>-que, and, if he's impatient, abort his request with @<nickname>-remove <file>, or cancel all of his requests by just entering @<nickname>-remove.
@<nickname>-hint is a "properiaty" MetalServe extension: users may use this command to inform the sysop about broken files (ie. corrupt archives, cut-off audio files etc.). Whether this extension is enabled and what MetalServe does with these hints can be configured using the hintsfile directive.
@find/ @locator in the mentioned scripts seem to be simple substring searches (that respect quoted phrases) instead of regular expressions or wildcards. MetalServe currently imitates this simple scheme, but will probably offer regular expression searches via a seperate @-keyword in the future.
Users must, of course, enable "Auto DCC GET" or a similar option in their clients, otherwise MetalServe will have a hard time trying to send even the first byte. Unfortunately, many users seem to have a broken firewall/router setup, so that you will have quite a few users where the DCC SEND won't seem to start.
For those reasons, MetalServe implements an internal ignore list that users will be added to for X minutes if repeatedly Y attempts to send a file failed. The intention is that they stop stupidly wasting send slots and queue positions and rather find the cause of the problem. This ignore list is of a temporary nature only, so if you want to permanently exclude someone you will have to add him to the "real" ban list using the ignore_users configuration directive.