There is no provision for that in the BitTorrent protocol. Therefore such a feature is near to impossible to implement at this point.
Your client is connecting with lots of other different clients (BitTorrent Mainline, Azureus, uTorrent, libtorrent, Ktorrent, ABC, rTorrent etc.; you name it). They would have to, all of them, support that, in order for it to work.
Maybe, on a theoretical level, BitComet could implement that as an extension to the protocol, based on the BitTorrent Extension Protocol but then again it would have to gain approval and be accepted, and what’s more, *implemented *by at least all the other major clients out there.
Otherwise you’ll just send messages out there, into the void.
And that’s a far fetched thought, seeing that most BitTorrent clients’ developing teams and communities, tend to be very territorial and reluctant to adopt features which they didn’t come up with, before others.
Another aspect to consider, is that, by looking at your Peers tab, you may see that the most part of your peers is constantly changing; it’s what makes the BitTorrent protocol so reliable and successful: it makes your client constantly seek out better peers and constantly evaluate the behavior of the connected peers as related to you and drop the connection with those which don’t meet its set of expected parameters.
Your connections with other peers are nothing like a stable HTTP/FTP connection your browser makes to a download server.
There may be thousands of peers in a swarm and during a download session your client may dynamically connect and disconnect with hundreds of them. And you don’t have any saying about which of them it will connect or how much a connection with any of them will last.
I hope that by now, you start to see my point, so I’ll rest my case.