Official eMule-Board: Protocol Enhancements - Howto? - Official eMule-Board

Jump to content


  • (20 Pages)
  • +
  • « First
  • 18
  • 19
  • 20

Protocol Enhancements - Howto? Which opcodes to use?

#381 User is offline   DavidXanatos 

  • Neo Dev
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1469
  • Joined: 23-April 04

Posted 16 June 2006 - 11:16 AM

I think there are already such describtions someware in the web.
This kid of informations is rather offtopic for the pure cross mod capability exchange. Only the initial handshacke protocol is relevant here.

The particular featuere are not yet relevant.
Yet we need only a clear capability exchange the rest is up to the creator of the feature.

Sorry, but I don't have the time yet to write a full eMule&eDonky protocoll guid for beginners and medium advanced codders.
Maby someware during the summer I'll finde the time...

Lets not just concentrate on the toppic the "capability exchange", ok.

David
NeoLoader is a new file sharing client, supporting ed2k/eMule, Bittorent and one click hosters,
it is the first client to be able to download form multiple networks the same file.
NL provides the first fully decentralized scalable torrent and DDL keyword search,
it implements an own novel anonymous file sharing network, providing anonymity and deniability to its users,
as well as many other new features.
It is written in C++ with Qt and is available for Windows, Linux and MacOS.
0

#382 User is offline   CiccioBastardo 

  • Doomsday Executor
  • PipPipPipPipPipPipPip
  • Group: Italian Moderators
  • Posts: 5541
  • Joined: 22-November 03

Posted 16 June 2006 - 12:56 PM

Quote

The ed2k header is 6 bytes long and contain 1 byte prot ID, 4 bytes packet length and 1 byte opcode ID.

So, can we change the prot ID to identify the mod prot?
Or this will create problems for parsing thses packets with respect to standard ED2K ones?
The problem is not the client, it's the user
0

#383 User is offline   DavidXanatos 

  • Neo Dev
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1469
  • Joined: 23-April 04

Posted 16 June 2006 - 01:10 PM

CiccioBastardo, on Jun 16 2006, 12:56 PM, said:

Quote

The ed2k header is 6 bytes long and contain 1 byte prot ID, 4 bytes packet length and 1 byte opcode ID.

So, can we change the prot ID to identify the mod prot?
Or this will create problems for parsing thses packets with respect to standard ED2K ones?
View Post

We can chenge the prot id like webcache already do, no problem, we must only go sure to send this mod packets only to mods that supports the mod prot.

David

This post has been edited by DavidXanatos: 16 June 2006 - 01:11 PM

NeoLoader is a new file sharing client, supporting ed2k/eMule, Bittorent and one click hosters,
it is the first client to be able to download form multiple networks the same file.
NL provides the first fully decentralized scalable torrent and DDL keyword search,
it implements an own novel anonymous file sharing network, providing anonymity and deniability to its users,
as well as many other new features.
It is written in C++ with Qt and is available for Windows, Linux and MacOS.
0

#384 User is offline   CiccioBastardo 

  • Doomsday Executor
  • PipPipPipPipPipPipPip
  • Group: Italian Moderators
  • Posts: 5541
  • Joined: 22-November 03

Posted 18 June 2006 - 02:54 PM

Hi,
it took me a bit to find some free time do do this.
It's not a great working, I know, but, well, I think a picture is worth one thousand words ;)

Hope it is clear enough:
Posted Image

You can get in PDF format as well:
ed2k://|file|Mod-prot.pdf|6678|F00953FBBED07A87AD57EFD1BF388839| |h=TEVRENPDMR76PTBEOBOIXMMBPW66R4XU|/

The focal point is the mod-tag. I think this way it can be completely future proof. You don't need a list of known tags or whatever. It may use a bit of space, but its completely worth its value, seen you can put whatever you want from here to the ethernity (and yes, I can create an easy solution if you need more than 64K bytes of payload! ;))

I don't know whether the tag count is useful or not. You see, the protocol can be extended to use both methods (just change the mod-id descriptor). With the mod-id descriptor it is possible to implement different "containers" as vectors for information.

About the upper level of the protocol , that is the content that can be inserted into these containers, with this solution everything is described by those mod-tags.
It may be required the first tag to contain the "dialect" used in the subsequent tags (this way more dialects can be supported).
Each dialect has a unique identified TAG-IDs.
We need only 2 reserved TAG-ID values: one for the Dialect tag, the other for the Mod-String which can be sent by this protocol independently whether the official supports it or not.
Each mod is not required to create his own dialect. A common language can be created. THen, if for some reasons, for example, Neo clients want to exchange more private data, they can create another dialect (a Dialect-Tag with an indentifier for Neo dialect) and follow with a new series of tags (whose id can overlap with other's dialect).

All is required is the ability to parse one kind of "container", ther mod tag, and to understand minimum 2 IDs: the language and the mod identifiers. By understanding them, I mean the mod has just to know that a tag is a language descriptor or a mod string descriptor. Then, it can ignore both (though ignoring the former is not really wise ;)).

All this is open to further discussion and make up.
The problem is not the client, it's the user
0

#385 User is offline   DavidXanatos 

  • Neo Dev
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1469
  • Joined: 23-April 04

Posted 18 June 2006 - 03:39 PM

The mod-tag's are not a problem we don't need to know the tag ID's only the tag types (data types storred in the tag) but we already have most or even all usefull tag types.
The kind of tags you describe are already in emule and called BLOB tags thei are binary data containers.

There is a mistake in your graphic, the ED2K header need to have the mod prot ID in the first byte.
The mod prot ID can not be in the payload of the packet, the OPCODE of the ED2K header already directs the packet to the proper reading code parts.

The picture describes generally what is already written in the wiki. :flowers:

The tag count is not needed as we read the tags from the mod info packet payload unstill the end if data is reached.

btw: the packet and the tag payload is not limited to 64 kb but to 4 GB

David

This post has been edited by DavidXanatos: 18 June 2006 - 03:40 PM

NeoLoader is a new file sharing client, supporting ed2k/eMule, Bittorent and one click hosters,
it is the first client to be able to download form multiple networks the same file.
NL provides the first fully decentralized scalable torrent and DDL keyword search,
it implements an own novel anonymous file sharing network, providing anonymity and deniability to its users,
as well as many other new features.
It is written in C++ with Qt and is available for Windows, Linux and MacOS.
0

#386 User is offline   CiccioBastardo 

  • Doomsday Executor
  • PipPipPipPipPipPipPip
  • Group: Italian Moderators
  • Posts: 5541
  • Joined: 22-November 03

Posted 18 June 2006 - 04:28 PM

Quote

There is a mistake in your graphic, the ED2K header need to have the mod prot ID in the first byte.
The mod prot ID can not be in the payload of the packet, the OPCODE of the ED2K header already directs the packet to the proper reading code parts.

No. That's an intended behaviour. The ED2K OP code signals that the packet is a mod-prot one. The Mod-id prot identifies which kind of container are used in the packet, or, however how to parse it.

Quote

The mod-tag's are not a problem we don't need to know the tag ID's only the tag types (data types storred in the tag) but we already have most or even all usefull tag types.

Again not. Please re-read the entire description to know why I thought about the general ID+size header. It's absolutely future proof and does not need to know any tag-type table. None can't make confusion by adding different types in whichever cronological order he wants.
That single type include all the others.

BTW, the mod-id identifier has been thought for this. If you want to use your own language (not simple dialect, which assigns different meaning to the same tag identifier), just use it.
As you an see 0x01 means that the language is described by a header with a tag-count followed by those standard tags.
0x02 means the tag count is not there (in near future one of these two proposed solutions may be abandoned once the pro and cons of both are deeply examined).
0x33 could mean: use NeoMule own crypted isolated language where you describe your features with stereograms.
BTW, see the difference in communication flexibility those solutions allows...

Quote

the packet and the tag payload is not limited to 64 kb but to 4 GB

The proposed tag has a size field of 16 bit, and being byte oriented, it can count to 64K which should be more than enough IMHO. A solution to overcome that is also considered if needed (but, as we are speaking of overhead here, who would send a 64K tag?).

Quote

The picture describes generally what is already written in the wiki.

With the difference that the picture can be understood by anyone :-k (at least I hope)

/edit: I'm also trying to write a real document on this mod protocol activity which will be updated as working progress.

This post has been edited by CiccioBastardo: 18 June 2006 - 04:30 PM

The problem is not the client, it's the user
0

#387 User is offline   DavidXanatos 

  • Neo Dev
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1469
  • Joined: 23-April 04

Posted 18 June 2006 - 05:05 PM

hmmm.... now I think I see how this is thought to be.
You identify the mod packet with the PROT ID of the ed2k header and its OPCODE but then you are adding into the payload of the packet a second header, Yes?
If yes, than sorry my fault I misinterpreted the picture on the begin.

There is also an other thing a bit confusing for me:
Whan a mod have a feature that is to be notyfyed in the 0x02 language.
but he also have a feature with the 0x33 language
how is the compatybility to mods with only 0x02 be granted?
Should he send more than one mod info packet, one with 0x02 for feature 1 and one with 0x33 for feature 2?
Wouldn't it be better to put the exclusiv/rare 0x33 stuff into a tag of the common 0x02?
At your example with Neo, I don't plan to use an non standard cross mod info I would use 0x02 and put obligatory stuff that don't fit the 0x02 specs in tags.

And how to keep backwards compatybility when 0x03 language is to be common agreed? Are the mods suposed to send also 0x01 and 0x02 for compatybility with older releases that can read only 0x01 and 0x02?

About the "ID+size header" tags just a single sentence: "emule already have this tag type", look for TAGTYPE_BLOB.
To avoid confusion we may agree to use only officialy supported tag types (howeever the ids should realy be longer than 1 char). Using official tags should be also future proved.
But as every feature belongs to a particular feature your simple binary tags fit all needs.

Could you add a 0x03 with official Emule tags (with longer IDs ofcause) inside to your picture.

Edit: About you picture, may I ask you with what software have you drawed it?

David

This post has been edited by DavidXanatos: 18 June 2006 - 05:36 PM

NeoLoader is a new file sharing client, supporting ed2k/eMule, Bittorent and one click hosters,
it is the first client to be able to download form multiple networks the same file.
NL provides the first fully decentralized scalable torrent and DDL keyword search,
it implements an own novel anonymous file sharing network, providing anonymity and deniability to its users,
as well as many other new features.
It is written in C++ with Qt and is available for Windows, Linux and MacOS.
0

#388 User is offline   leuk_he 

  • MorphXT team.
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 5975
  • Joined: 11-August 04

Posted 18 June 2006 - 06:00 PM

CiccioBastardo, on Jun 18 2006, 06:28 PM, said:

Quote

The picture describes generally what is already written in the wiki.

With the difference that the picture can be understood by anyone :-k (at least I hope)

/edit: I'm also trying to write a real document on this mod protocol activity which will be updated as working progress.
View Post



I asumme that the 0x01 under the fields are the lengths? (May i add the pic to the talk page of the wiki? )

next to the record layoyt there should also be some protocol: when to send what data. more pics! i like pics! :clap:
Download the MorphXT emule mod here: eMule Morph mod

Trouble connecting to a server? Use kad and /or refresh your server list
Strange search results? Check for fake servers! Or download morph, enable obfuscated server required, and far less fake server seen.

Looking for morphXT translators. If you want to translate the morph strings please come here (you only need to be able to write, no coding required. ) Covered now: cn,pt(br),it,es_t,fr.,pl Update needed:de,nl
-Morph FAQ [English wiki]--Het grote emule topic deel 13 [Nederlands]
if you want to send a message i will tell you to open op a topic in the forum. Other forum lurkers might be helped as well.
0

#389 User is offline   CiccioBastardo 

  • Doomsday Executor
  • PipPipPipPipPipPipPip
  • Group: Italian Moderators
  • Posts: 5541
  • Joined: 22-November 03

Posted 18 June 2006 - 06:14 PM

DavidXanatos, on Jun 18 2006, 06:05 PM, said:

hmmm....  now I think I see how this is thought to be.
You identify the mod packet with the PROT ID of the ed2k header and its OPCODE but then you are adding into the payload of the packet a second header, Yes?
If yes, than sorry my fault I misinterpreted the picture on the begin.

Huh, no. I kept the ED2K protocol identifier as it is. I was wondering if it could be changed, but I didn't know.
If it can be changed you can use the ID PROT for the MOD-PROT identifier and the OP code to define which language. That will save a byte.

Quote

There is also an other thing a bit confusing for me:
Whan a mod have a feature that is to be notyfyed in the 0x02 language.
but he also have a feature with the 0x33 language
how is the compatybility to mods with only 0x02 be granted?
Should he send more than one mod info packet, one with 0x02 for feature 1 and one with 0x33 for feature 2?
Wouldn't it be better to put the exclusiv/rare 0x33 stuff into a tag of the common 0x02?
At your example with Neo, I don't plan to use an non standard cross mod info I would use 0x02 and put obligatory stuff that don't fit the 0x02 specs in tags.

And how to keep backwards compatybility when 0x03 language is to be common agreed? Are the mods suposed to send also 0x01 and 0x02 for compatybility with older releases that can read only 0x01 and 0x02?

A language is a completely defined rule of message parsing in this case.
A mod should not really mix different languages. It should use only one (if you are talking with a mod that can undesrstand 0x33 use it, it it can use 0x02 revert to to it).
If you want to mix them, you have to send 2 different messages with different language-ids. The idea of languages is not of being "compatible". That's the opposite, as for any langauge (even the spoken one). There's should be a valid reason to create one's own language. The most obvious is to not allow other clients to understand what you are saying (that's what Miccroshit does at every Office release). Which is not the intended goal here, but it is allowed for maximum flexibility. The standard tag-id+size+payload method is already able to include whatever feature you want to add, I think.

Quote

About the "ID+size header" tags just a single sentence: "emule already have this tag type", look for TAGTYPE_BLOB.
To avoid confusion we may agree to use only officialy supported tag types (howeever the ids should realy be longer than 1 char). Using official tags should be also future proved.
But as every feature belongs to a particular feature your simple binary tags fit all needs.

I really didn't looked at the already supported tags. As the proposed tag is really simple and highly flexible I thought it as being the only one supported. The ID only indicates the meaning of the content, not the type. It should simplify the parsing a lot (much less if-then-else constructs). I proposed 16 bit identifier as they are usually the best trade off between diversification and used space. Having the chance to define different dialects still increases the identifier options.

Quote

Could you add a 0x03 with official Emule tags (with longer IDs ofcause) inside to your picture.

Hey, I have not to add anything myself. This is a proposal. If you think that a languages with the current supported type is needed, well, it can be added without problems.

Quote

Edit: About you picture, may I ask you with what software have you drawed it?

Microshit Visio. Then I grabbed the screen :P (yeah, it's a real problem converting those vector drawings into bitmap ones...)

So, I can go changing the MOD-PROT id part?

This post has been edited by CiccioBastardo: 18 June 2006 - 06:14 PM

The problem is not the client, it's the user
0

#390 User is offline   DavidXanatos 

  • Neo Dev
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1469
  • Joined: 23-April 04

Posted 18 June 2006 - 06:29 PM

CiccioBastardo, on Jun 18 2006, 06:14 PM, said:

DavidXanatos, on Jun 18 2006, 06:05 PM, said:

hmmm....  now I think I see how this is thought to be.
You identify the mod packet with the PROT ID of the ed2k header and its OPCODE but then you are adding into the payload of the packet a second header, Yes?
If yes, than sorry my fault I misinterpreted the picture on the begin.

Huh, no. I kept the ED2K protocol identifier as it is. I was wondering if it could be changed, but I didn't know.
If it can be changed you can use the ID PROT for the MOD-PROT identifier and the OP code to define which language. That will save a byte.

.....

So, I can go changing the MOD-PROT id part?

If you don't change the ed2k prot ID or at least the opcode in the ed2k header the packet will be passed to some emule code part of whitch are as many as used opcodes.

The best sollution is to use a ModProt that will be a medium for all mod packets and identyfy your info packet by a specyfyed opcode, simmilar like webcache do.

changing the prot ID is not a problem it requirers only minor changes in the CEMSocket, but: do Never send a packet with an alternated prot it to a cleint that does not supports it, if you do this he will immidetly terminate the connection.

David
NeoLoader is a new file sharing client, supporting ed2k/eMule, Bittorent and one click hosters,
it is the first client to be able to download form multiple networks the same file.
NL provides the first fully decentralized scalable torrent and DDL keyword search,
it implements an own novel anonymous file sharing network, providing anonymity and deniability to its users,
as well as many other new features.
It is written in C++ with Qt and is available for Windows, Linux and MacOS.
0

#391 User is offline   CiccioBastardo 

  • Doomsday Executor
  • PipPipPipPipPipPipPip
  • Group: Italian Moderators
  • Posts: 5541
  • Joined: 22-November 03

Posted 18 June 2006 - 07:29 PM

As shwon in drawing v0.1 the message belonging to the mod-prot was meant to be identified by using an OP code.

If the Prot ID is modifiable, then you can use that. Closing the communication when sending crap to a client not supporting it is a bonus, IMO.

So, here the modified v0.2:
Posted Image

I used tag 0xAA for mod prot id as I didn't know what to use :P. Another one can be used as well.

I think this second version is better than the first one as:
1. a byte is spared
2. you have to be sure the remote client understands the mod protocol, otherwise the communication is going to be closed (better than a ban)
The problem is not the client, it's the user
0

#392 User is offline   DavidXanatos 

  • Neo Dev
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1469
  • Joined: 23-April 04

Posted 18 June 2006 - 07:37 PM

ok, looks better, :+1:
but 1 thing, the lang ID should be inside the mod info packet and not put into the header itself this way we can use this headder also for other mod packets.
The 1 byte OH is not relevant, and putting the lang id into the mod info packet itself is a much cleaner sollution.
And from the practical coding point of view it is also better.

David

This post has been edited by DavidXanatos: 18 June 2006 - 07:37 PM

NeoLoader is a new file sharing client, supporting ed2k/eMule, Bittorent and one click hosters,
it is the first client to be able to download form multiple networks the same file.
NL provides the first fully decentralized scalable torrent and DDL keyword search,
it implements an own novel anonymous file sharing network, providing anonymity and deniability to its users,
as well as many other new features.
It is written in C++ with Qt and is available for Windows, Linux and MacOS.
0

#393 User is offline   CiccioBastardo 

  • Doomsday Executor
  • PipPipPipPipPipPipPip
  • Group: Italian Moderators
  • Posts: 5541
  • Joined: 22-November 03

Posted 18 June 2006 - 08:33 PM

Mumble... this is all about comunication standard.. how would you process a new mod packet if you do not know which language it uses?
I was thinking about this header as the base for every other communication process. Changing what is now defined the language ID just determines how to parse the subsequent packet content. What is contained in the packet is not important at this level. A client parsing this header knows 2 things: we are speaking an alternate language that is not the standard one through the PROT ID, and which language it is going to be used (or, which sub protocol) throuh the OP Code (now LANG ID in the MOD PROT).

Which kind of packet were you thinking about that cannot be described by this model?
The problem is not the client, it's the user
0

#394 User is offline   DavidXanatos 

  • Neo Dev
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1469
  • Joined: 23-April 04

Posted 19 June 2006 - 05:59 AM

I thought that other mod packets would be associated with particular features and the features would implicates a feature language.
So that we only need to have a standardised way to exchange our capabilities/features we support.
We would know by opcode to what feature the mod packet belongs and so we would know how to parse it.

Puting all feature communication in such packet format would work but I think It wouldn't bring any advantage as by the mod info informations we already know all languages spoken by the remote cleint and together with the packet opcode we know how to parse a packet, or we know that this is a unsupported packet.

But the idea is quite interresting, it would make the communication some how more resistent to parsing errors, so we can send in a packet RPS status and SCT map, and blabla info, and if we fail on parsing the SCT map we could still read the blabla info.

hmm...

David
NeoLoader is a new file sharing client, supporting ed2k/eMule, Bittorent and one click hosters,
it is the first client to be able to download form multiple networks the same file.
NL provides the first fully decentralized scalable torrent and DDL keyword search,
it implements an own novel anonymous file sharing network, providing anonymity and deniability to its users,
as well as many other new features.
It is written in C++ with Qt and is available for Windows, Linux and MacOS.
0

#395 User is offline   CiccioBastardo 

  • Doomsday Executor
  • PipPipPipPipPipPipPip
  • Group: Italian Moderators
  • Posts: 5541
  • Joined: 22-November 03

Posted 19 June 2006 - 09:03 AM

I think that the proposed ModTag is easier to use as a unique supported communication block. At least it defines the simpler (though highly flexible) language. As said, other kinds of languages can be defined using the LANG ID, implying the rules that are needed to parse the packet content.

Quote

I thought that other mod packets would be associated with particular features and the features would implicates a feature language.

Huh, no. You do not need to specify a new language to create a feature description, if that was what you meant. You just need to create the tag content and describe it.
For example it could be possible to define the Mod string tag with the proposed MOD tag in this simple way:
Tag ID: 0x0077
Tag Size: 16
Payload: "My wonderful mod v1.0"

A tag for the mod version could be used as well to isolate it from the string version
Tag ID: 0x00CC
Tag Size: 2
Payolad: 0x0100

I used a 16 bit field with 8 bit for the version on 8 bit for the subversion 0 for revision. But a 5-5-6 format could be used. Or even a 8-8-8. The dialect would define the format of the 0x00CC tag (and alternatives can be created also using the size field).

It is also possible with this tag to ALWAYS insert the version of the feature. We can decide that the first byte of the payload always contains the version of the feature, so that versioning problems are solved in a standard way.
Tag ID: 0x55 - Extended comment
Tag Size: 39
Payload: 0x01 + "This in a long comment that I'm sending you through the alternative mod protocol, as it is not allowed to send this with the official one"

or
Tag ID: 0x55 - Extended comment
Tag Size: 220
Payload: 0x35 + "This in a long comment that I'm sending you through the alternative mod protocol, as it is not allowed to send this with the official one and I'm adding a file hash that is related to the file you are downloading" + 0x1234567890123456

The correspondance between version and feature extension should be unique, though this is not a thing any language can achieve by itself.

These are just examples with randomly chosen IDs.

Quote

So that we only need to have a standardised way to exchange our capabilities/features we support.
We would know by opcode to what feature the mod packet belongs and so we would know how to parse it.

That is a legitimate language that can be used as well, though the parsing code would be a bit more complex to implement, IMHO.

@Leuk_he
I missed your post yesterday, sorry. Yes, the number under the blocks are their dimensions is bytes. I made a quick sketch of those blocks and didn't inserted a precise description. Sorry. I'll try to make a completely understadable drawing for next versions of the document.
Of course these pics can be inserted into the Wiki with no problems.
I'm writing a document as well to be published in PDF format. For now it is really at a larval stage. In the next days I'll submit the contents to you all so you can add/change/correct anything you want.
This document may become the official reference to the Mod protool extension. For this, I would like other modders that here have still not expressed their thoughts to comment on it when made available.

Thanks in advance

/edit: corrected the size of the extended comment tags :ph34r:

This post has been edited by CiccioBastardo: 19 June 2006 - 05:03 PM

The problem is not the client, it's the user
0

#396 User is offline   Andu 

  • Morph Team
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 13015
  • Joined: 04-December 02

Posted 19 June 2006 - 02:11 PM

Finally the bickering is over and this is getting somewhere. I hope the modders will all give their input so that we can get the best solution for the network and mod community.
Three Rings for the Elven-kings under the sky,
Seven for the Dwarf-lords in their halls of stone,
Nine for Mortal Men doomed to die,
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.
One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.


Dark Lord of the Forum


Morph your Mule

Need a little help with your MorphXT? Click here

0

#397 User is offline   CiccioBastardo 

  • Doomsday Executor
  • PipPipPipPipPipPipPip
  • Group: Italian Moderators
  • Posts: 5541
  • Joined: 22-November 03

Posted 27 June 2006 - 06:43 AM

For anyone interested, the discussion has moved here

Anyone is invited to partecipated, but please, keep it clean of any spamming/trolling attempts.
The problem is not the client, it's the user
0

  • Member Options

  • (20 Pages)
  • +
  • « First
  • 18
  • 19
  • 20

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users