Talk:$MyINFO

Extended MyINFO, useful on hubs stripping client tags (passive user complains without tags -> without known other users mode). 

$MyINFO $ALL <nick> <description>$<modechar>$<connection><flag>$<e-mail>$<sharesize>$|

Support

Hubs:

Clients:


I removed this from the article because I've never seen a hub supporting it. Nor does DC++ support it. Can anyone shed light on this? --GargoyleMT 17:38, 30 January 2006 (EST)
There is no such thing as "Extended" MyINFO when doing MyINFOs striping.

MyINFOs stripping is done by hubs to save bandwidth while keeping everything working Hubs<-->Clients<-->Clients. The only fields that seems critical for it to work for all clients are: $MyINFO $ALL <nick> $ $<connection><flag>$$0$ <connection>: some bots are recognized with this. <flag>: some clients rely on it to detect "chat only" and some require it for parsing the MyINFOs (for example DC++ on myinfo without connection and flag show connection like $$0$).

Clients share size: client share in GB, the minimum share require to enter the hub in GB.(both are rounded to an integer value) or is the real share size.

Note: OPs always see real clients' MyINFOs

If the author of this, "while striping Extended MyINFO", request, want that implemented in hubs that do MyINFOs striping, he should ask the hubs makers...

--TheNOP

Author of this don't need to ask hubs makers because "Extended" MyINFO is already 1.5 year supported with good hubsofware and good clients. // PPK

Er... okay. Why not just say what supports it? Judging by your 'good' comments, you presumably mean the two pieces of software that you're responsible for - CZDC++ and PtokaX. Your style of saying that is bizarre, to say the least. --GargoyleMT 07:53, 2 February 2006 (EST)


MyINFOs striping might have been around for quite some time now, but there are no standard in the way to implement it. For our part, DDCH support MyINFOs striping.(Only when sending them to unregistered users and the feature is enable). It is implemented in a way to save maximum bandwidth while staying compatible with all clients. I don't see why the MyINFOs should be only partially striped. If clients were to notify the users each time he try to connect to a passive users that would be an other story, but they don't. Other hub makers might think differently and allow some of the field(s) to be kept or to let hub owners decide by themselves by allowing to strip any part(s) they want. But to my knowledge no hubsoft allow stripping all MyINFOs parts separately. --TheNOP

There is a warning in DC++ 0.68 and later about downloading from passive users in passive mode. I think there was a mechanism before that version as well - a $RevConnectToMe in response to a $RevConnectToMe was the indication that the remote user was in passive mode. I believe the queue item was then removed. --GargoyleMT 11:49, 8 February 2006 (EST)
Does the warning in DC++ 0.68+ rely on connection mode or it is still using "$RevConnectToMe in response to a $RevConnectToMe" detection ?
--TheNOP
It will set the passive bit in response to the value in the tag, but it will also set it in response to a passive search or the double $RevConnectToMe. --GargoyleMT 08:34, 11 February 2006 (EST)
Personal tools