(Ir)Responsibility of client developers

Site Announcements
klondike
Member
Posts: 73
Joined: 14 Nov 2010, 13:06

Re: (Ir)Responsibility of client developers

Post by klondike » 18 Feb 2011, 10:01

Crise wrote:So demanding an immediate fix like that is completely out of line... if an ADC hub software can not deal with communication that follows the specification then the hubsoftware is faulty in that it expects all the clients connecting to it "behave well" and not send excessive number of updates (like in this case). God if all http servers just expected all http clients to behave well (instead of having safeguards) where would the world wide web be.
You are going down through a dangerous lane here, look how easy is to do a DOS (or a DDOS) to almos any service thanks to the way the TCP protocol is usually implemented ;-)

IMHO I think that the FS feature could be more useful if generized I mean, having a command to send field updates to the MYInfo instead of the whole MYInfo seems reasonable. I have to say I haven't reread then new updates to the extensions, so it may be already published and I didn't realize.

Toast

Re: (Ir)Responsibility of client developers

Post by Toast » 18 Feb 2011, 14:11

already published fixed and now adchpp has a real anti flood guarding script thats gonna be merged pretty soon already available here on adcportal and on lp

andyhhp
Junior Member
Posts: 30
Joined: 18 Feb 2010, 17:44
Location: England

Re: (Ir)Responsibility of client developers

Post by andyhhp » 18 Feb 2011, 20:31

I think that the FS feature could be more useful if generized I mean, having a command to send field updates to the MYInfo instead of the whole MYInfo seems reasonable.
It seems to me that you think you need to rebroadcast the entire INF if any field updates in it?

~Andrew

klondike
Member
Posts: 73
Joined: 14 Nov 2010, 13:06

Re: (Ir)Responsibility of client developers

Post by klondike » 18 Feb 2011, 20:55

Toast wrote:already published fixed and now adchpp has a real anti flood guarding script thats gonna be merged pretty soon already available here on adcportal and on lp
:o All I can say is that now I have strong reasons to start forcing movement towards ADC.
andyhhp wrote:It seems to me that you think you need to rebroadcast the entire INF if any field updates in it?
Yes, am I wrong? Haven't reread the specs in a long time and may have forgotten a few things.

Pretorian
Site Admin
Posts: 214
Joined: 21 Jul 2009, 10:21

Re: (Ir)Responsibility of client developers

Post by Pretorian » 20 Feb 2011, 21:06

klondike wrote:
andyhhp wrote:It seems to me that you think you need to rebroadcast the entire INF if any field updates in it?
Yes, am I wrong? Haven't reread the specs in a long time and may have forgotten a few things.
Yes, you're wrong. You only send what's changed. (In NMDC, on the other hand, $MyINFO must be sent with all of the information.)

klondike
Member
Posts: 73
Joined: 14 Nov 2010, 13:06

Re: (Ir)Responsibility of client developers

Post by klondike » 22 Feb 2011, 02:24

Pretorian wrote:
klondike wrote:
andyhhp wrote:It seems to me that you think you need to rebroadcast the entire INF if any field updates in it?
Yes, am I wrong? Haven't reread the specs in a long time and may have forgotten a few things.
Yes, you're wrong. You only send what's changed. (In NMDC, on the other hand, $MyINFO must be sent with all of the information.)
Ok, thanks for correcting me then, as I said its been sometime since I read the protocol (though I'll have to do it again I'm afraid).

Locked