New $Support: SmartProtcol
Moderator: Moderators
New $Support: SmartProtcol
Hey guys,
Ive been working with dc for quite some time now, and ive come up with an idea that will allow hubs to contain at least 2 times more users
I've called it SmartProtocol. Here's the jist of it:
Instead of the server taking the load for bouncing $Search's and $ConnectToMe's around, SmartProtocol will allow clients to do the work.
It involves clients sending their tcp\udp info in the $MyINFO string
- $IpAddress:tcpPort:udpPort$
This means when users connect to the hub, the hub will send the tcp\udp info for each user to each user!
Now that each user in a hub has eachothers Address and Ports. They are able freely search and connect with eachother without interacting in the hub.
Now this does have one exploit if left open. It makes all the users open in the hub. So each user MUST DISCONNECT any connecting user on the tcp port when the $MyNick and IP Address doesnt correspond to a user connected in one of the connected hubs
I would also suggest adding a $HubName command so users can check what hub the connection is comming from.
This also has one more very good side to it.
IT STOPS WANKERS BEING ABLE TO FLOOD DC USERS TO PREFORM DOS ATTACKS!
So i ask, What do we think?
Ive been working with dc for quite some time now, and ive come up with an idea that will allow hubs to contain at least 2 times more users
I've called it SmartProtocol. Here's the jist of it:
Instead of the server taking the load for bouncing $Search's and $ConnectToMe's around, SmartProtocol will allow clients to do the work.
It involves clients sending their tcp\udp info in the $MyINFO string
- $IpAddress:tcpPort:udpPort$
This means when users connect to the hub, the hub will send the tcp\udp info for each user to each user!
Now that each user in a hub has eachothers Address and Ports. They are able freely search and connect with eachother without interacting in the hub.
Now this does have one exploit if left open. It makes all the users open in the hub. So each user MUST DISCONNECT any connecting user on the tcp port when the $MyNick and IP Address doesnt correspond to a user connected in one of the connected hubs
I would also suggest adding a $HubName command so users can check what hub the connection is comming from.
This also has one more very good side to it.
IT STOPS WANKERS BEING ABLE TO FLOOD DC USERS TO PREFORM DOS ATTACKS!
So i ask, What do we think?
-
- Posts: 506
- Joined: 2003-01-03 07:33
$HubName has never been static. Different users can recieve different HubNames while being connected to the same hub. So hubname can not be trusted or used in this context.
I can see several more flaws in you suggestion but i urge you to read up on the ADC-proposal farcry pointed you towards before adressing them.
I can see several more flaws in you suggestion but i urge you to read up on the ADC-proposal farcry pointed you towards before adressing them.
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.
ADC is a new protocol and isnt based on the current dc protocol whatsoever.FarCry wrote:ADC offers that and the risks have already been discussed here.
Im not to sure on it all,but if u have 2 types of protocols in the one hubsoft, the hub then has to translate protocol calls for each client.
This just wont happen in my mind
What im talking about is an extension of the current protocol so it can support more users and take out the exploits that cause dos attacks forever!
Well, im not sure u got me on the $HubName protocol command.ivulfusbar wrote:$HubName has never been static. Different users can recieve different HubNames while being connected to the same hub. So hubname can not be trusted or used in this context.
I can see several more flaws in you suggestion but i urge you to read up on the ADC-proposal farcry pointed you towards before adressing them.
In my idea, this is how it would work as a short protocol example:...
Client1 connects to server and sends tcp\udp info with $MyINFO
Client1 sends its $Search to all clients on their upd ports (without server)
Clients reponse to the $Search as per normal on the udp port (yes this can be exploited,but no worse then it currently is)
Client1 Connects to Client2 for download\upload
Client1 Sends $MyNick $HubName
Client2 Checks if $MyNick is in $HubName with the correct IP Address
Client2 Disconnects Client1 when fakes a connection attempt for downloading\uploading
It's flawless, and fake clients cant get into the hubs clients unless they are connected to the hub!
Futher discussion is needed =] ...
hmm, yea ur right,[NL]Pur wrote:Client1 sends its $Search to all clients on their upd ports (without server)
How do you verify the identity of client1 in case of the second step sending the search ?
Well i guess we would need $MyNick and $HubName in the search, as it already contains the ip address.
Then the clients can dismis the $Search command if its fake (from a kazza network! ewww)...
but why would u fake the ip in the $Search string?[NL]Pur wrote:Bare in mind that:
it's udp, ip are easy fakeable many clame that
you know with your construction everyones nick+ip combination
Because no clients would be able to send the search returns.
So it would defeat the purpose of trying to search
The problems are the same for both protocols. In ADC 0.10, UDP searches will be restricted to trusted environments, because of the dangers brought up in that wiki article. Your goal was to increase the number of users a hub can handle, which is seldom an issue for the small communities someone considers trusted. For an extension to a protocol that already has numerous client and server implementations running, the possible gain is not worth the effort in my opinion. I personally doubt its value even for ADC.Corayzon wrote:ADC is a new protocol and isnt based on the current dc protocol whatsoever.
Yea ur right,[NL]Pur wrote:But that would be something of wrong implementation and not flawed by design. But correct me if i'm wrong there.
But then at least these dos attacks can only take place on other users within the hub, rather then any tcp\upd connection in the world.
The risks are far less then the current protocol, correct me if im wrong ^^
Ive read this like 5 times, and it just keeps going out the other ear :SFarCry wrote:The problems are the same for both protocols. In ADC 0.10, UDP searches will be restricted to trusted environments, because of the dangers brought up in that wiki article. Your goal was to increase the number of users a hub can handle, which is seldom an issue for the small communities someone considers trusted. For an extension to a protocol that already has numerous client and server implementations running, the possible gain is not worth the effort in my opinion. I personally doubt its value even for ADC.Corayzon wrote:ADC is a new protocol and isnt based on the current dc protocol whatsoever.
Im not sure what ur pointing towards there sorry FarCry
Hmm, yea, any current hubsoft can correct the issues with dos attacking with only a few lines code.
But remember, im not trying to fix any current issues. Im only trying to make this network bigger, better and smarter.
Im allmost sure if we sat down and thought about the $Search exploit in my implementation, we could devise a solution that removes the risks
But remember, im not trying to fix any current issues. Im only trying to make this network bigger, better and smarter.
Im allmost sure if we sat down and thought about the $Search exploit in my implementation, we could devise a solution that removes the risks
Just like Pur explained to you (and the wiki article describes in detail), your idea comes with a vulnerability to client and hub DDoS attacks, which makes it only usable in environments where every client trusts every other client. You should perhaps have followed the link instead of just saying that it's a different protocol.Corayzon wrote:Im not sure what ur pointing towards there sorry FarCry
Others sat down about this and the only possible solution seems to be signing those searches to avoid identities being spoofed, which is inacceptably complicated.Corayzon wrote:Im allmost sure if we sat down and thought about the $Search exploit in my implementation, we could devise a solution that removes the risks
silly me not reading shit properly,FarCry wrote:Just like Pur explained to you (and the wiki article describes in detail), your idea comes with a vulnerability to client and hub DDoS attacks, which makes it only usable in environments where every client trusts every other client. You should perhaps have followed the link instead of just saying that it's a different protocol.Corayzon wrote:Im not sure what ur pointing towards there sorry FarCry
it will be the death of me i tellz ya
Last edited by Corayzon on 2006-01-07 11:52, edited 1 time in total.
-
- Posts: 9
- Joined: 2005-12-03 06:20
- Location: South Africa