AT2k Design BBS Message Area
Casually read the BBS message area using an easy to use interface. Messages are categorized exactly like they are on the BBS. You may post new messages or reply to existing messages! You are not logged in. Login here for full access privileges. |
Previous Message | Next Message | Back to BBS Support/Help/Discussion <-- <--- | Return to Home Page |
|
||||||
From | To | Subject | Date/Time | |||
Nick Andre | Ogg | Re: Proper way to "freq" |
March 2, 2023 1:10 PM * |
|||
On 01 Mar 23 21:02:50, Ogg said the following to All: O> In some of the network echos, I've seen several messages that report you can O> "freq" files. I understand what the file request means. I've just never be O> able to find any documentation on how to properly format a netmail to O> accomplish this task. Can anyone point me to any documentation or a "how to O> on freq'ing? Freq means file-requesting and can mean two different things. A "bot" which answers your Netmail and sends you the file, or the functionality of a Fidonet mailer that supports Bark or Wazoo style requests. I am not familiar with systems that have Netmail bots to send files because this could have potential for abuse and several systems may not have file attachment-routing enabled in their mailers by default. By the time one sends a Netmail to a bot and wait for a reply, they could "Google it". It appears that often there must be a special routing arrangement involved in the Sysops who run systems with file-bots. What you will likely find is the latter, and there is no Netmail involved - A system generates a ".REQ" file containing the filenames or magic-names of files to request. A magic-name is simply an alias for a file. For example, magic-name MICRONET could mean to request the latest Micronet nodelist. In some cases, special requests to password-protected directories can be made. The mailer then directly connects / Crash calls the other system via dialup modem using Emsi, Wazoo or FTS-0001... Or in some cases Internet BinkD. The .REQ file is sent and the mailer waits usually between 30 seconds to 2 minutes for the other system to fulfill the request and send back the desired files. The real fun is watching what happens to that .REQ file when it gets received on the desired BBS that desired file is on. The desired BBS must first make sure only certain files may be sent, sometimes requests can be denied as most mailers have sets of rules and security policy that are often applied to stop abuse or "leeching" everything from that person's BBS. How many times did the caller Freq today, how much KB's or MB's worth of files were transferred... how often does he Freq restricted files. The mailer must also take into account what happens if the request is for a file that is on a network share, CD or DVD drive; multiple requests spanning multiple directories may need to be indexed or staged so the Freq request completes in the short turn-around time allowed. In some cases a BBS Sysop may choose not to put his whole file collection up for access because his mailer simply cannot crawl through a large collection in time... unless the mailer uses a complex set of database/index tables to speed things up for him. You will not find many BBS's today that support FREQ's by BinkD because the BinkD system on the desired BBS must invoke an external process to read the generated SRIF (System-requesting information file) and read the received .REQ to figure out what files to send back in that same session. This is called an external SRIF or FREQ processor and these programs often are beyond the scope of most Sysops to make then run... except for the sadomasochists. The simple act of Freq-ing files involves a LOT of logic and programming in the software supporting it. It is almost as complex as handling BBS callers. D'Bridge can do all of this with just one menu command. Nick --- Renegade vY2Ka2 * Origin: Joey, do you like movies about gladiators? (618:500/24) |
||||||
|
Previous Message | Next Message | Back to BBS Support/Help/Discussion <-- <--- | Return to Home Page |
Execution Time: 0.0161 seconds If you experience any problems with this website or need help, contact the webmaster. VADV-PHP Copyright © 2002-2024 Steve Winn, Aspect Technologies. All Rights Reserved. Virtual Advanced Copyright © 1995-1997 Roland De Graaf. |