LFG Forwarder

10 - Need smarter algorithm for selecting the forwarder

TradeForwarder has become quite popular on my server (US-Antonidas) and at any given time there are usually several people in a city who are eligible to perform forwarding. Currently the addon somewhat randomly selects the forwarder from the available toons in city whenever the current forwarder leaves the city.

This simple policy has a few unfortunate consequences. Most obviously, it tends to favor toons who hang out in cities for long periods of time, possibly because they are spamming trade. This is bad because If receivers have ignored or reported-spam on the current forwarder, they will not get any forwarded messages. This is basically the problem reported in ticket 8.

A more subtle but equally problematic consequence of the current implementation is if the FORWARDER has ignored many toons, then any messages from those toons are blocked at the forwarder and won't appear to any of the receivers (despite the fact they may not have the original sender ignored). This can result in some very confusing situations because TFW has no way to detect or report this behavior to either user, so trade chat on the receiver can be just silently missing messages from the receiver's friends.

To combat both of these problems I believe a smarter forwarding policy is justified. I think the best solution to combat both these problems is to have ALL the clients who are in cities attempting to forward trade messages, and use a heuristic to remove the duplicates. This provides the most complete forwarding possible, and with a handful of random forwarders should usually eliminate most messages dropped due to inter-toon ignores.

The simplest implementation would just be to have every client in a city always forward every trade message, and use a heuristic at the receivers to remove the duplicate messages from the display of the resulting channel. The downside of this approach is that with many forwarders the bandwidth requirement for the hidden messages may eventually become a concern. A smarter algorithm would additionally add a pseudo-random delay of up to a few seconds at each forwarder before forwarding each message, and cancel the forward upon seeing a duplicate message sent by another forwarder with an earlier pseudo-random time. This should usually result in very little bandwidth bloat, modulo server channel latency.

What are your thoughts on this warbaby? Is this a feature you'd like to see?

User When Change
oscarucb Oct 25, 2011 at 05:30 UTC Create

You must login to post a comment. Don't have an account? Register to get one!

Facts

Reported
Oct 25, 2011
Status
New - Issue has not had initial review yet.
Type
Enhancement - A change which is intended to better the project in some way
Priority
Medium - Normal priority.
Votes
0

Reported by

Possible assignees