This is a discussion on exosee update within the P2P General Discussion forums, part of the P2P Forums category; well he had to and the major reason for this was that exosee changed from a multiport system (port 715 ...
well he had to and the major reason for this was that exosee changed from a multiport system (port 715 to 725 tcp) to a single port system (port 714 tcp) also there was the addition of the moderating system inside the cs wich needed alot of modification to the code also now the system uses a form of database system for the xoc multilink
So now if your ISP or network blocks port 714, then you will be totally locked out? I don't like that idea then. Modern P2Ps let you set your own port number to evade port blocks - which used to be very common a few years ago, back when most P2Ps were single-port and port-blocks worked.
yes in fact i would be block fortunatly for me my isp does not care about it atleast for now also i think there is also work done at the moment to make exosee use variable port ,anyway exosee is far from been finished each new version bring its new option and function some of them are not noticible while other are but yes you are right on that for now
I was quite happy with the old version of Exosee. It's too bad that there seems to be no public servers still running 0.99 compatible software.
Exosee had some excellent innovations introduced- like public/private shared folders and its integrated webserver, but unfortunately development seems to have slowed in the last year or so, not unlike a lot of other closed-source non-commercial P2Ps.
well it still as the private and public folder you can enven by putting a user in your favorite specify a folder that only this user can access wich is even better then before as for the slow down yes the release are not comming as fast as they where but whe have to be patient as its not a team that is working on it but one person
Maybe someday Exosee will be open-sourced; then development should be much faster. I think the only time when closed-source is an advantage is when the protocol is encrypted, or it has other security features like IP spoofing, or randomized misinformation.
not sure but i think it isOriginally Posted by tm
hm yeah from what i've heard the exosee protocol is encrypted! do u know when there will be a final release or at least a beta with search function?
well i dont know if he is planning on adding it back for the next version but ill ask ,i know that for now he is working hard at reimplementing the new xoc multisource protocol but i havent talked with him about the search function ,ill try to see with a couple of other user if they have talked to him about it and i will get back to you with any info i may gather
I always felt that the XOC protocol was headed in the wrong direction from the beginning by setting chunk size of 2MB. Both eDonkey and eMule discovered from experience that the original ED2K chunk size of 9MB chunk - the smallest unit that is hash-verified - was much too large because it was frequently exploited by malicious users seeding the network with corrupt data and seriously undermining the release of files. What often happned in ED2K is that a malicious uploader would upload a few bytes at a time to every user and every chunk, thus preventing anyone from ever completing a single segment because they would all be corrupt even though only a few bytes out of 9MB would actually be corrupt.
In response to hostile uploaders, eDonkey set a sub-chunk hash of 256K and eMule a 180KB size, but were still stuck with the original 9.28MB for backward compatibility. If they could have gone back in time, the original chunk size would have been set much smaller, but of course it was too late because there are so many existing hash links already posted.
While there is more overhead when chunk sizes are smaller, experience has shown that this is more than offset because a corruption - often intentionally created - will require a re-download of a much smaller amount of data.
The original spec for the Tree Hash EXchange format (also known as Merkle hashes) stated:
2.3 Choice Of Segment Size
Any segment size is possible, but the choice of base segment size establishes the smallest possible unit of verification.
If the the segment size is equal to or larger than the file to be hashed, the tree hash value is the value of the single segment's value, which is the same as the underlying hash algorithm value for the whole file.
A segment size equal to the digest algorithm output size would more than double the total amount of data to be hashed, and thus more than double the time required to calculate the tree hash structure, as compared to a simple full-file hash. However, once the segment size reaches several multiples of the digest size, calculating the tree adds only a small fractional time overhead beyond what a traditional full-file hash would cost.
Otherwise, smaller segments are better. Smaller segments allow, but do not require, the retention and use of fine-grained verification info, (A stack-based tree calculation procedure need never retain more than one pending internal node value per generation before it can be combined with a sibling, and all interim values below a certain generation size of interest can be discarded.) Further, it is beneficial for multiple application domains and even files of wildly different sizes to share the same base segment size, so that tree structures can be shared and used to discover correlated subranges.
Thus the authors recommend a segment size of 1,024 bytes for most applications, as a sort of "smallest common denominator", even for applications involving multi-gigabyte or terabyte files. This segment size is 40-50 times larger than common secure hash digest lengths (20-24 bytes), and thus adds no more than 5-10% in running time as compared to the "infinite segment" size case -- the traditional full-file hash.
Considering a 1 terabyte file, the maximum dynamic state required during the calculation of the tree root value is 29 interim node values -- less than 1KB assuming a 20-byte digest algorithm like SHA-1. Only interim values in generations of interest for range verification need to be remembered for tree exchange, so if only 8GB ranges ever need to be verified, all but the top 8 generations of internal values (255 hashes) can be discarded.
you point of view on the subject tm as be fowarded to chag as i think its interresting for him to know about it
on a second note nms04 i have ask chag about the search function and it unfortunatly seem that the search function wont be in the next beta i have been told that with the implementation of the remade xoc protocol and life occupation in general time was laking and that the search function would not make it in for now
Maybe I should join the Exosee forum and talk more about the importance of setting a small segment size.
I have had several ed2k files that were impossible to complete because of this malicious corruption. When this happens, only way I was ever able to complete even a single segment of the file was by blocking out each and every bad IP address with the firewall - and sometimes there were dozens of different IPs uploading the same corrupt file.
Edonkey and eMule clients both now exchange a secondary checksum with other clients, but this would not have been necessary if the segment size had been set to a smaller value at the beginning so that the hashlink contained this 180KB-256KB hashed chunk, instead of the easily-corruptable 9MB chunk size.
sure go ahead there is a lack of user that are technicly inclined in the forum wich if there where would greatly improved the development of exosee so yeah do please do
Posting Permissions 
LinkBack URL
About LinkBacks
Reply With Quote
Bookmarks