dmvn

Member
 View profile  See their activity

  • Content count

    75

  • Joined

  • Last visited

Posts posted by dmvn

  1. Posted

    i think this feature can be a bit dangerous because it should allow malicious users to bypass antispam filters in hubs ( if i understood the request )

    +1. Any antispam/antiflood control mechanisms ars based on passing-through-hub all control messages, including PM. This will break the scheme. Of course, if this disabled on target machine, no spam will flow.

    BTW, ApexDC is a filesharing program. And chat/PMs are secondary functions... Anyway, this will lead to additional options/settings window overload, etc... I think we should wait while other clients will (or not!) support this feature... And then add it... This is not the case when Apex should be the first one who supports this... We have many other interesting extensions to work out.

    All typed above is only M.H.O ;)

  2. Posted

    Существенное добавление к предыдущему посту. STLport надо брать из svn, иначе ничего работать не будет. STL 5.1 не годится, вряд ли вообще соберётся.

  3. Posted

    Damn it, what the hell is going here? Why do you talking about FlyLink??? This is the APEX forum, no?

    VamKir, your translation is rather good, but... there are some bugs/not-russian-phrases: i'm native Russian, so i know the language well. Is your translation posted there is the last available one? I believe i can fix some strange phrases in it... So please guide me to the latest one, and i'll produce a .patch. Also i can put it into svn repo to track down all changes...

    [cp1251]

  4. Posted

    The bug concerns nick copying/sending public messages.

    How to see:

    1) rightclick any nick in Chat and do "Copy nick".

    2) rightclick another user in the userlist and do "Send public message".

    You'll see that first nick (that was copied in the 1st step) was placed in msg window, but, of course, message should be addressed to the second one.

    PS. I've asked to test my friends this on StrongDC 2.12 -- they have the same result.

    Maybe this is a feature... but then it's a strange one ;)

  7. Posted

    it's not possible, because filelist is global but emulation is hub dependent.

    also I am against this feature because it will increase filelist size rapidly.

    I agree with Greg: somebody who wants to use this feature, *will* sacrifice DC++ compatibility. This option must force disabling 'dc++ compat' checkbox, and vice versa. Then people will be able to make their own choice.

    Uff, filelist size... This field is the UNIX timestamp... So it's 10-15 bytes per shared file... Not so much, especially for modern HDDs and LANs.

    Anyway, sounds good. For it.

  8. Posted

    I have nothing against it, I would probably use it, but if it's ruled out because there's too many options already I won't be heart broken. :)

    The great rule sounds like that:

    There cannot be too many settings/options. There can be a bad interface/layout.

    But it's not the case :) The color selection window is organized well, so I see no evil if one more item adds to the list.

    But this feature improves readability of long conversations... :)

  11. Posted

    SATA and SCSI drives can transfer at this speed I agree, but since when, has a 100Mb trans rate been considered slow??

    Well, probably you're not working with large files :( 'Slow' is a RELATIVE characteristic :( Smth can seem slow for me and seem FAST for you :) If you think that 100M is enough for any user, you can just sit back and relax, we understand you completely :)

    The most interesting is that, indeed, in the 1G-network i really cannot achieve speeds more than 20-25 megs per sec via Apex/sDC/... although wind0ze can transmit files quicker. First, i dont want you to change DC protocol, etc... The only thing i want to understand, what can slow such a fast transfers... Small blocks? Insufficient disk cache? Slow CPU? Smth else? I suggested smth above, but there were only guesses. It's not a problem (because we can use another protocol), but... now I'm interested in knowing what component is the real bottleneck. Hint: the answer 'HDD' is wrong, obviously. The only one idea is that windows can achieve speeds ~30-40Mbytes/sec over 1G-LAN when data on HDD is arranged in a large linear block. When any fragmenation present, it drops to 15-18 megs, or so on. So i think that this can be a main reason (blockish behaviour of DC creates 'turbulence' and slows processs).

  12. Posted

    So a quick benchmark, very rough. But transferring a 10gig file across the network(via windows) takes about 1-2minutes. Transferring the same file with ApexDC takes about 10-15mins.

    Thats basically the problem. I tryed to edit the config file to add a 1000 option, but it did not make any difference.

    This is not connected with 100M Limit. This is, more probably, connected with the nature of DC++ protocol itself... Small chunks, hash checking, alternate searching... etc... Windowz performs faster as it doesn't do a half of it, it sends only data.

  13. Posted

    well for starters that speed in general page has no impact on anything whatsoever... it is just info sent to hubs, but which has no real meaning on anything.

    Of course, i DO understand it. But this means I cannot provide adequate info for hub while using 1G-connections :)

    This is a tiny bug/typo, of course... :) Well, you may name it as you wish, but the solution is so easy...

  14. Posted

    The HDD speed DOES matter.

    For example, an PATA drive will allow a Max write speed of 55Mb/s in every day usage, so how can you say it doesn't matter?

    I said so because it's obvious that HDD speed (for modern HDDs) is MUCH MORE than 100 Mbit (that is maximum in "Settings->General" window).

    L3PG8MB8BC.png

    I think this is so easy do add one more item for conn spedd combo... :)

    Well, i provided the example of the real situation (and can also make some screenshots to prove...) where this setting can be useful... What any arguments you need?

    <offtopic>PATA HDD... Oh yes... Such a slow devices... Wide IDE connectors.... Nostalgy.... </offtopic>

  15. Posted

    BM, it does not matter at all! One HDD can fill upto 1/3-2/5 of 1G-uplink.

    But i think there is no problem at all... Or, at least, no serious problem... I also have 1G uplink in my LAN, but other computers connected using 100M-switches, so each of them can load it's own channel up to the full capacity. When all limits turned off, I often watch upload speeds like 20-25 megs per second, so DC allows such fast transmissions indeed, although maximum connection speed is set at 100M (in settings). Please note I have no RAID arrays, that allow speeds like 100-150 Mbytes/sec :)

    So, the suggestion is the only to add one more item to ConnSpeed combo-box, named "1000M" or "1G".

  16. Posted

    Well, i passed this problem in another way -- and done it much more effective... :) I've changed the DC protocol a bit for my special anti-leech hub and compiled a special DC client without any leeching/cheating options. Nobody can connect this hub using other client, due to protocol modification. This client still can connect to other hubs using standard DC protocol (there is a special autoswitching mechanism). So i don't need to ban/detect leeching mods -- i should only set up minsharelimit and minimal upload speed than can be done in hub settings. That's all.

    Please note that this solution is used in 100mbit-LAN with free internal traffic, not over Internet, so we don't violate anything -- we only want from users to share more :) This is not applicable for Inet hubs where different users use different (f.ex ADSL, hence slow) connections...

  18. Posted

    Well, i'm not a beta tester, but it's so easy to check...

    Using apex 1.0.1 built from source.

    I swap some tabs, then closed apex. Then opened it again. The tabs order is saved. I tried it three or four times in different ways -- everything is OK. So if there any bug, it lies deeper than the surface...

    I recommend two things:

    1) ensure that you're using *LAST* version of apex.

    2) try to *delete* all settings, leave bare .exe and run it again (and then check behavior) -- maybe you put your new .exe into your beta5's folder (i noticed some strange effects including share flushing, maybe this is the next one...)

    Sorry if any flood :)

  19. Posted

    Oh **** :) You're right :D

    So much settings, so much options... As for me, my implementation is more useful, but this is only IMHO, anyway. Thanx for advice, next time i'll read the source code more review code more carefully, although i revised "Experts only" section....

    The one thing still remains useful in my post... Would you like to adjust the layout of Appearance dlgbox, as shown? More precisely, extend space for "AWAY msg" to the width of the dialog, and move timestamp box to bottom. It's quite easy, but improves design, because AWAY message shall be long enough to see the whole message, while the path for langfile can be short as nobody actually enters it with hands, i believe everybody uses

    "Browse" button :)

  20. Posted

    I added a useful feature to my apex mod that I watched some months ago in speedmod. The Chat Message now can be resized up to 10 lines of text, like this:

    Decpxsmjx6.png

    And this is the new Appearance window (yellow box marks the new setting control).

    1UsY733t4P.png

    Also I optimized the layout of Appearance dlgbox (shown with the red frame): the AWAY message was too short, and the path to langfile is too small... (this is also included in this patch).

    I tried to add .patchfile as attach to this post, but it failed, so here is the direct link... (why .bz2 files are not acepted??? :D )

    http://dmvn.myftp.org/soft/chatmessage.patch.bz2 (svn diff with the 1.0.1 final version taken from site).

    Hope this will be merged into the project :)

    Any comments, wishes?

  22. Posted

    Well, if implemented, so the *exe-backup* must be the important sub-feature of auto-updater. Afaik, some settings transfer incorrectly while moving to new versions (f.e the share problem noticed at 1.0.0.b5-->1.0.1.Final, also the quicksearch window was invisible until i deleted /Settings folder, and so on...).

    Sure, this feature/setting must be disabled by default (or we get thousands of angry users at new release date).

  24. Posted

    Feel free to submit your changes as .patch file (other formats are fine too though), because as far as committing goes... I am the only one who is doing that, pretty much.

    OK, thank you... :) Let the force of diff be with me...

  25. Posted

    Nice work, thank you for some notes about stlport. I've managed to compile 1.0.1 with the latest STLport from svn repo.

    Before reading this topic i have a strange trouble -- no slider in the main window that allows to resize userlist window while being compiled with the _old_ stlport library (i don't exactly remember what version, but < 5.1.5) and the standard patched WTL from strongdc site.

    When upgraded to new stlport and recompiled it, everything is OK, the slider is moving. Decided to notice this, to avoid same mistakes on the final release (due to no same effect achieved at 1.0.0.beta5!).

    PS. /me wants to commit some useful things that I've modded in beta5... (chat msg/private frame msg resizing, etc...)...