Now I discussed the hottest topic discussed in P2P technology. I am afraid how I don't pass unharmable delivery files without passing the server (of course, the extensive statement is to pass the information), I don't have this expert, It has not fully found the spiritan medicine of "unobstructed delivery file". This problem is really tricky, because even the most representative JXTA now, the information does not completely reach this requirement, but also through rendezvous Peer (Set Point) or Routerpeer (Route Peer), GatewayPeer, etc. to assist in transfer - of course, JXTA adheres to Jini's advanced ideas and features, in the current network environment, I think this should be the most ideal. P2P design (in another topic, I will be more detailed and explore). As for MSN, QQ, ICQ, etc., I want to be a typical centralized server representative, there is no need to discuss! What I want to discuss here is to break through the double (multiple?!) SOCKS proxy server without relying on a dedicated transit server, and in the case where the gateway (or even the export of external network) is installed. Many people have expressed doubts about this view, and even a few people say that there are even a few people say that there is a few people say that there is a small number of people. More, I hope to tell this skill.
For IT technology, this is a very normal, I am not "you don't believe, I will let you see", because my demo has been released, and the people who are very fast have to try. I know that true and false, so I am not intentional to come to this kind of purpose! I just want to exchange here, the right to throw a brick, I hope everyone will make progress! Noteping less (otherwise someone is thrown with tomatoes, ^ _ ^) still does not understand the Socks agent agreement first to http://www.china-pub.com/computers/emook/emooknew/rfctxt/rfc1928.txt rush down Electric, don't understand the basic TCP / IP protocol, please understand, or you will listen to the cloud! Breaking the blockade of the double SOCKS proxy server to deliver files, simply, puts such a network situation, peera1 (peer A1) is connected to the interconnect network through Peera, connected to the interconnect network through Peera, and installs SOCKS on PEERA Proxy server, peerb1 (peer B1) In the B local area network, connect to the interconnection network via Peerb, PEERB is installed on the peerb, as follows: -------------- --------------------------------------- Peera1 (192.168.0.3)
It must first create a TCP connection to the SOCKS port on the SOCKS server. Usually this TCP port is 1080. When the connection is established, the client enters the protocol "Handshake" process: the selection of the authentication method, authenticated according to the selected manner, and then send forwarding requirements. The SOCKS server checks this requirement, depending on the results, or establishes a suitable connection, or refuses. Unless otherwise indicated, the decimal numbers that appear in the data packet format map represent the length of the corresponding domain in bytes. If a certain domain needs to give a value of one byte, use x'HH 'to represent the value in this byte. If a domain is used in a field 'variable', this means that the length of the domain is variable, and the length is defined in a domain associated with this domain (1 - 2 bytes), or a data type field. in. After the client is connected to the server, then the request is sent to negotiate version and authentication methods: VERNMETHODSMETHODS111 To 255 This version of the SOCKS protocol is set to X'05 '. The NMETHODS field contains the number of methods indicated in the Methods field (in bytes). The server selects one of these given methods and sends a method selected back to the client: vermethod11 If the selected message is X'FF ', this means that there is no method in the method list listed by the client, the customer The end must be closed. The current definition method is:? X'00 'does not need to authenticate? X'01' gssapi? X'02 'username / password? X'03' - X'7f 'is assigned by IANA? X'80' - X'FE 'is reserved for a private method without an acceptable method and then the client and server enters the sub-negotiation process determined by the selected authentication method (Sub-Negotiation). For a variety of sub-negotiation processes of various methods, please refer to the respective memos. If you want to get a method number for your own method, you can contact IANA. You can refer to the list of all the names that have been assigned to get the current all methods and the corresponding protocols. The SOCKS V5 implementation that meets this document must support GSSAPI and support the username / password authentication method in the future. 4. When the request is completed, the client will send a detailed request information. If the negotiation method has a package with integrity check and / or security, these requests must be encapsulated in the way they are defined in this method. The format of the SOCKS request is as follows: vermdrsv atypdst.addrdst.port11x'00'1variable2 where the Ver protocol version: X'05 '? Cmd? Connect: X'01'? Bind: x'02 '? Udp associate: X'03' • RSV reserved? Add IPv4: X'01 '? Domain Name: X'03'? Ipv6: X'04 '? DST.Addr destination address? Dst.Port The port number appeared in the network byte order. The SOCKS server analyzes the request according to the source address and destination address and then returns one or more answers based on the request type. 5. The address type included in the address field (DST.Addr, Bnd.Addr) is described in the address atyp field: • X'01 'based on IPv4 IP address, 4 bytes long? X'03' based on domain name address, address The first byte in the field is the length of the domain name in bytes, and there is no NUL byte ending.
• X'04 'based on IPv6 IP address, 16 bytes long 6. The response has established a connection to the SOCKS server, and the negotiation process of the authentication method will be completed, the client will send a SOCKS request information to the server. The server will return according to the request in the following format: verreprsvatypbnd.addrbnd.port11x'00'1variable2 where:? Ver protocol version: X'05 '? REP Answer field:? X'00' success? X'01 'ordinary SOCKS Server request failed? X'02 'existing rules are not allowed? X'03' network is not arrogant? X'04 'host is not reached? X'05' connection is rejected? X'06 'TTL timeout? X' 07 'does not support command? X'08' does not support address type? X'09 '- x'ff' undefined? RSV reserves? Atyp's address type? IPv4: X'01 '? Domain Name: X'03 '? Ipv6: x'04'? Bnd.addr server binding address? Bnd.Port The field identified by the server bound by the server binding of the network byte order must be set to X'00 '. If the selected method is packaged in integrity checking and / or security, these responses must be encapsulated in the manner defined in this method. Connect In a response to a connection command, Bnd.Port contains the port number used to connect to the target machine, and Bnd.Addr is the corresponding IP address. Since the SOCKS server usually has multiple IPs, Bnd.Addr is often different from the client to the IP of the SOCKS server. The SOCKS server can use Dst.Addr and Dst.Port, and the client source address and port to analyze a Connect request. Bindbind requests are usually used on protocols that require clients to accept connections from the server. FTP is a typical example. It establishes a connection from the client to the server to execute the command and the reception status, and uses another connection from the server to the client to receive transmission data (such as LS, GET, PUT). It is recommended that only the second connection can be established using the bind command after using the client command to establish a primary connection after using the connection protocol. It is recommended that the SOCKS server uses dst.addr and dst.port to evaluate bind requests. During a BIND request, the SOCKS server wants to send two answers to the client. Send the first answer when the server is established and binding a new socket. The Bnd.Port field contains the port number used to listen to the entered connection, and the band.addr field contains the corresponding IP address. The client usually uses this information to tell (through the primary connection or control connection) Application server connection. The second response only happened to the desired arrival connection success or failure. In the second response, the Bnd.Port and Bnd.Addr fields contain the IP address and port number of the last host. UDP Associateudp Associate requests are usually requested to establish a UDP forwarding process to control the UDP datagram. Dst.addr and Dst.Port fields contain the IP address and port number of the client you want to send the UDP datagram. The server can use this information to limit access. If the client does not have address and port information when sending this request, the client must use all 0 to populate. When the TCP connection is interrupted with the UDP, the UDP connection must also be interrupted. When the UDP Associate request, the Bnd.Port and Bnd.Addr fields indicate that the client sends a UDP message to the port and address of the server.
Answering Processing When an answer (the REP value is not equal to 00) indicates an error, the SOCKS server must terminate the TCP connection within a short period of time after sending a reply message. This time should be less than 10 seconds after discovering errors. If a response (REP value is equal to 00) indicates success, and the request is a BIND or Connect, the client can start sending data. If the negotiated authentication method has a package of integrity, authentication, and / or security, these requests must be encapsulated in the way they are defined in this method. Similarly, when the data is reached with the SOCKS server as a server-destination, the SOCKS server must encapsulate these data with the method being used. -------------------------------------------------- --- I saw it, I just used this handshake process to establish the connection from Pera1 to Peerb, in short, as long as the agreement, even if the proxy server can also establish a connection from Peera1 to Peerb! What, what I want, how come from Pera1 to Peerb1, from Pera1 to Peerb, I will be eight hundred years ago! Don't worry, carefully observe this handshake process, 1 Send request to negotiate version and authentication method: 05 01 00 (No code verification request, if the password verification request, send 05 02 00 00), then wait back; 2 If successful, Then, "then" then "then" then "Sub-Negotiation) determined by the client and server." 3 Now that the subscriber negotiation has been completed and successful, OTHED returns 00, then "once After the negotiation process, the client sends a detailed request information ", now, suppose we send" Detailed Request Information "as: 05 01 00 01
If the request data sent by the first step can be the same as the request data sent by the third step. . . . The first step, 05 01 00. . . The third step, 05 01 00 01
