May be pure digital, it may be letters and numbers combination.
this is not the place to solicit work from paid freelancers. Use a site like http://www.freelancer.com for that. Or just search online, there are plenty of examples and forum discussions related to how to use Indy, particularly TIdHTTP, to interact with HTTP web pages.
However, I speak English you may be difficult to understand, gradually began to feel it.
is Indy supposed to handle IPv6 "automatically"?
not "automatically", no. You need to manually set the connection's IPVersion property to Id_IPv6 (unless you recompile Indy with IdIPv6 defined in IdCompilerDefines.inc, then IPVersion will default to Id_IPv6). In the case of TIdHTTP specifically, it obtains server info from a URL instead of set properties, so if you want to connect to an HTTP/S server using IPv6, you need to wrap the host portion of the URL in brackets. RFCs 2732 and 3986 require brackets around IPv6 IP addresses only, but TIdHTTP currently requires brackets around hostnames as well if you want it to perform an IPv6 DNS lookup. Indy is currently dependant on the IPVersion property being set and is not coded to resolve a hostname to both IPv4 and IPv6 at the same time and then attempt every address reported until a connection is successful. It lookups a hostname to either IPv4 or IPv6 only and then attempts a connection to the first IP reported only.
There is currently no GStack.SupportsIPv4, though (in work) to handle the case of IPv6-only systems.
..and thanks
A bug in Indy TCP, it losses data!!!
In TIdTCPServer.OnExecute
SetLength(arrBuf, 0);
argContext.Connection.IOHandler.ReadBytes(arrBuf, -1);
OnReceive(@(arrBuf[0]), Length(arrBuf));
In the callback function OnReceive, counts the "Length(arrBuf)", the total number of bytes received. After 10000 times sending, there are about 9000~16000 bytes losed.
In TIdTCPServer.OnExecute
SetLength(arrBuf, 0);
argContext.Connection.IOHandler.ReadBytes(arrBuf, -1);
OnReceive(@(arrBuf[0]), Length(arrBuf));
In the callback function OnReceive, counts the "Length(arrBuf)", the total number of bytes received. After 10000 times sending, there are about 9000~16000 bytes losed.
ReadBytes() does not lose data (unless you are performing reads across multiple threads at the same time and corrupting the IOHandler.InputBuffer). You are asking ReadBytes() to return whatever arbitrary bytes are currently available at the time it is being called. However, when AByteCount is -1, ReadBytes() always reads from the socket first, even if there are pending bytes still in the InputBuffer. If there are no new bytes on the socket at that moment, it waits for the IOHandler's ReadTimeout to elapse before then returning whatever is in the InputBuffer. And ReadTimeout is set to infinite by default. So, if there is pending bytes in the InputBuffer, not no new bytes on the socket, ReadBytes() will not return until the next client send. You could check IOHandler.InputBufferIsEmpty() first, and if False then call IOHandler.InputBuffer.ExtractToBytes() directly, otherwise call ReadBytes() instead.
However, that is actually not necessary, because your server code is wrong to begin with. Your client is sending a data packet that has a fixed header on it that includes the data size in it. You server code is completely ignoring that header. You need to have the server read the header, then read the specified number of bytes, then you can pass the completed packet to OnReceive. Then there is no problem.
SetLength(arrBuf, 8); argContext.Connection.IOHandler.ReadBytes(arrBuf, 8); argContext.Connection.IOHandler.ReadBytes(arrBuf, PInteger(@arrBuf[4])^, True); OnReceive(@arrBuf[0], Length(arrBuf));
Note that you are sending integers in host byte order, which means you are subject to endian differences between the client and server. You really should be using network byte order instead. If you are not going to use the IOHandler's Read/Write methods for integer values, at least use Indy's GStack.HostToNetwork() function before sending the data, and the GStack.NetworkToHost() function after receiving the data, to make sure the integers are in a consistent endian on the wire.
PUInt32(@ sendBuf [0])^ := GStack.HostToNetwork(UInt32(CMDCOMMU_HEADER)); PUInt32(@ sendBuf [4])^ := GStack.HostToNetwork(UInt32(bufsize)); ... PUInt32(@ arrBuf [0])^ := GStack.NetworkToHost(PUInt32(@ arrBuf [0])^); PUInt32(@ arrBuf [4])^ := GStack.NetworkToHost(PUInt32(@ arrBuf [4])^);
Otherwise, use the IOHandler's reading/writing functions: with cmdClient.fIdClient.IOHandler do begin Write(Int32(CMDCOMMU_HEADER)); Write(Int32(bufsize)); Write(buf); end; ... with argContext.Connection.IOHandler do begin PktType := ReadInt32; PktSize := ReadInt32; ReadBytes(arrBuf, PktSize); end;
Do uses GStack.HostToNetwork to prevent some network device reading error?
What is the point of putting a fixed header on the packets if your server is not going to use the header for reading the packet? You really shouldn't be doing arbitrary reading in this situation. You know the exact data size up front, so just ask Indy to read that many bytes. Problem solved.