Talk:$UserIP

Sedulus

I extended the reply to include more than one user. The syntax is:
$UserIP <username 1> <ip number 1>$<username 2> <ip number 2>$<username 3> <ip number 3>$...
(a $ between every user-IP-combination; no $ after the last)

The idea is that the server sends one full list of all connected users with corresponding IP's at login, and one $UserIP for every new client logging in. This would normally only be sent to privileged users (Operators). It eliminates the need for the client to send the $UserIP request for every user it wants info on.

NOTE: this hasn't been approved by any design committee ;-)

fusbar

If this is added as Sedulus wants, wouldn't $$ be a more natural delimiter? Then this list would follow the beaviour of $NickList and $OpList. I.E something like
$UserIP <username 1> <ip number 1>$$<username 2> <ip number 2>$$<username 3> <ip number 3>$$...$$

NOTE: Not that it matters, i only prefer something unified.

Sedulus

alrighty.. I'll change it in the DCH++023 $UserIp plugin,
I hope DC++ handles empty nicks in the $UserMap (for users of my previous dc++ mod)

DC++ implementation - arnetheduck

DC++ identifies its support for this with the c-h $Supports scheme, hubs must send $Supports UserIP2 for DC++ to use it (so that DC++ won't send commands to hubs that don't understand it). It calls the feature UserIP2 for two reasons, the original userip didn't support lists of users, and DC++ differs from the original implementation in that it never asks for its own ip; it assumes it's always sent out to a compilant hub. The command itself that's sent from the hub is still "$UserIP blah" though, no changes there.

DC++ will never ask for its own ip, it'll assume that the server will send it out if the server supports UserIP and detects $Supports UserIP2, just as it skips GetINFO if possible. On a side note; IMHO hubs should always send out all users ip's, they're known anyway to any client that wants to connect to another one, and this could be used in $usercommands...(or perhaps even connect Directly (it's direct connect after all...) instead of going through the hub...)