Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Dec 11 10:55
    TommySlokky commented #274
  • Dec 11 10:54
    TommySlokky commented #274
  • Dec 11 10:54
    TommySlokky commented #274
  • Dec 11 10:53
    TommySlokky commented #274
  • Dec 11 10:53
    TommySlokky commented #274
  • Dec 11 00:36

    rlebeau on master

    Minor tweak to last pull reques… (compare)

  • Dec 11 00:29

    rlebeau on master

    fix compiling issues for IdStac… Merge pull request #273 from Bi… (compare)

  • Dec 11 00:29
    rlebeau closed #273
  • Dec 11 00:27
    rlebeau commented #275
  • Dec 11 00:26

    rlebeau on master

    Defining HAS_PRawByteString for… (compare)

  • Dec 11 00:19

    rlebeau on master

    Define PRawByteString for older… Merge pull request #275 from Bi… (compare)

  • Dec 11 00:19
    rlebeau closed #275
  • Dec 10 22:05
    Bi0T1N commented #274
  • Dec 10 21:36
    Bi0T1N commented #275
  • Dec 10 21:31
    Bi0T1N synchronize #275
  • Dec 10 19:25
    rlebeau commented #275
  • Dec 10 19:21
    rlebeau commented #275
  • Dec 10 14:50
    TommySlokky commented #274
  • Dec 10 14:39
    TommySlokky commented #274
  • Dec 10 14:37
    TommySlokky commented #274
Kudzu
@czhower
hrdware
@hrdware
The only thing I have been able to find on www.indyproject.org is version 10.0.52 which says is an old version and no longer recommended.
Kudzu
@czhower
It does nto say that. Please read the text more carefully. Use the dev snapshot
hrdware
@hrdware
I will look at the dev shapshot, but right under the link for dev snapshot it says, "Alternatively you can download the Source Code for Version 10.0.52. This is however a rather old version and is no longer recommended."
Kudzu
@czhower
Read ABOVE that and note the word "alternatively"
hrdware
@hrdware
@rlebeau So just to be clear, I can download the indy10_5438.zip file and extract the indy110. files and install those dpk files (after uninstalling the previous version) and then I should be all set. Correct?
Remy Lebeau
@rlebeau
@hrdware in theory, yes, provided you don't have any other components installed that depend on the version of Indy that shipped with the IDE.
hrdware
@hrdware
I was able to get indy10_5438 downloaded and installed, however I do not see a way to generate a sha256 hash with this version in Delphi 2007. Am I missing something in this version or did I misunderstand something I read about sha256 in this version/delphi version? Thx for any help.
Remy Lebeau
@rlebeau
@hrdware there is a TIdHashSHA256 class in the IdHashSHA unit. But Indy does not natively implement SHA hashes other than SHA1 (that is a TODO item: IndySockets/Indy#169), other SHA hashes require external hashing code be hooked up to Indy at runtime. By default, Indy provides an implementation of SHA hashes using OpenSSL. Just add the IdSSLOpenSSLHeaders unit to your uses clause, call IdSSLOpenSSLHeaders.Load() at program startup, and deploy the 2 OpenSSL DLLs (ssleay32.dll and libeay32.dll) with your app. Then TIdHashSHA256 (and other TIdHashSHA... classes) should work. If you want to use a different hashing implementation, you can certainly do that, just hook up the SHA256 function pointers in the IdFIPS unit to whatever implementation you want.
hrdware
@hrdware
@rlebeau I saw that somewhere, and I was looking for that unit but I don't seem to have it in the lib\protocols directory. Is it in some other location?
Remy Lebeau
@rlebeau
@hrdware no, that is the correct folder. It does exist in Fulgan's ZIP, I just checked
hrdware
@hrdware
So once I get to Fulgan, I went into the ZIP folder and then downloaded the Indy10_5438.zip file. Is there another file I need to get?
nevermind...I found it in one place I extracted my files to, but on the place I copied them to. I will remove the install and try it again
Remy Lebeau
@rlebeau
@hrdware no, there is no other file, that is the correct one
hrdware
@hrdware
@rlebeau OK, so now I'm confused....I am not super familiar with installing components so I am fumbling around a bit here. I opened all the DPK files and compiled them and installed the cdlIndyCore and dclIndyProtocols after compinling. I thought this would place all the files I needed into the correct Delphi Directories. Do I need to add some other directory to my application search path?
Remy Lebeau
@rlebeau
@hrdware that depends on your IDE and its configured output paths when compiling the packages. Been a long time since I used 2007
hrdware
@hrdware
@rlebeau OK, thanks, that gives me a direction to look in. Your help is much appreciated.
Kudzu
@czhower
blob
Kudzu
@czhower
blob
New website in the works.
milosdeymed
@milosdeymed
Hello Indy people, I have strange problem using simple UDP (indy 10.6.2.5341 in Delphi 10.1). We have internet connected to mother board and device sending udp packets on different card (poe), we receive 320 packets/s, size 1190kB. And we only receive all packets when some continuous data flows trough the other (internet) interface - for example youtube video. if I stop the video, packet loss occures.
it seems to me as power saving mode or something like that on windows network layer. I do not know how exactly to troubleshoot this. wireshark shows continuous data flow.
milosdeymed
@milosdeymed
We found solution, there was bad handling of multiple packets in buffer and somehow the thread reading packets probably gets to the CPU more frequently when there was traffic on network stack.
mercedwang
@mercedwang
I have created a Linux console app by using TIdTCPServer in Delphi 10.2 Tokyo. I found that the action of setting the Active property of the component to False costs a long time (about half an hour) if the TCP server socket has one or more active connections. However the server socket can be closed quickly if it has no connection. What's the matter?
Matthijs ter Woord
@mterwoord
probably its waiting for connectinos to be terminateds
mercedwang
@mercedwang
@mterwoord However the same code runs very smoothly in Windows platform
mercedwang
@mercedwang
@mterwoord In the OnExecute event handler, I only call AContext.Connection.IOHandler.ReadBytes() to read a byte from the client. After one or more connections have been established, those connections are terminated and TCP server socket are closed very quickly on Windows platform. if the Active property is set to False. However the main thread is frozen for al long time on Linux if the same operation is executed.
Matthijs ter Woord
@mterwoord
no clue. never used indy on linux
well, that is, last 15 years..
mercedwang
@mercedwang
@mterwoord Thanks anyway. How to report this problem to the Indy team?
Matthijs ter Woord
@mterwoord
wait till someone responds here.. :)
Remy Lebeau
@rlebeau
@mercedwang Indy uses blocking sockets, and infinite timeouts by default. When the server is deactivating, it closes all of its active sockets. Closing a socket in one thread is not guaranteed to unblock any blocked socket operations in other threads. It does on Windows, but it may not on all platforms. Try setting the IOHandler.ReadTimeout property to a short timeout and then handle any EIdReadTimedOut errors that occur. Or, before calling IOHandler.ReadBytes() (why not ReadByte()?), you can check IOHandler.InputBufferIsEmptyand if True then call IOHandler.CheckForDataOnSource() with a timeout, and skip ReadByte(s) until the IOHandler.InputBuffer actually has something available to read.
Kudzu
@czhower
Iirc it should unblock when closed from other thread and its defined and expected behavior across platforms.
Remy Lebeau
@rlebeau
@czhower I've seen reports from time to time where a blocking socket operation in one thread is not unblocked when the socket is closed from another thread. Indy is currently coded to expect it to always work on all platforms, but it doesn't always work on all platforms.
Kudzu
@czhower
Ive only ever seen it as a bug in some os patched. Check orig socket docs and I believe it is documented. Lots of software depends on this, especially on *nix.
mercedwang
@mercedwang
@rlebeau I follow ur suggests and implement my own ReadBytes procedure. Now it works very well.
procedure ReadBytes(IOHandler: TIdIOHandler; var VBuffer: TIdBytes; AByteCount: Integer; AAppend: Boolean = True);
const
CheckInterval = 5000;
var
InitialTimeout, Timeout: Integer;
NewDataAvail: Boolean;
begin
Assert(Assigned(IOHandler.InputBuffer));
InitialTimeout := IfThen(IOHandler.ReadTimeout >= 0, IOHandler.ReadTimeout, MaxInt);
while IOHandler.InputBuffer.Size < AByteCount do begin
Timeout := InitialTimeout;
repeat
if Timeout <= 0 then raise EIdReadTimeout.Create(RSReadTimeout);
NewDataAvail := IOHandler.CheckForDataOnSource(Min(CheckInterval, Timeout));
IOHandler.CheckForDisconnect(True, True);
Dec(Timeout, CheckInterval);
until NewDataAvail;
end;
IOHandler.InputBuffer.ExtractToBytes(VBuffer, AByteCount, AAppend);
end;
Kudzu
@czhower
I did some digging, and it looks like there is a bug affecting you. *nix does conform and closing a socket from one thread will err out recv/send calls in other threads.
Some users have reported that some linux builds are not doing this, but its incorrect behaviour and can break lots of apps.
It seems to be a recurring problem on Linux from what I can see.
mercedwang
@mercedwang
@czhower Thank u. Before the closing behaiours become consistent among different Linux distributions, I'd like to use the code above to workaround this problem.
mercedwang
@mercedwang
Another problem. It seems that most recent Linux distributions allow binding IPv4 and IPv6 on the same port concurrently. Will the implementation of adding bindings in TIdCustomTCPServer.Startup become more flexible in the future?
Remy Lebeau
@rlebeau
@mercedwang I don't see how your ReadBytes() implementation is much better than the current TIdIOHandler.ReadBytes() implementation. If you set a non-inifinite positive ReadTimeout, an EIdReadTimeout should already be getting raised by TIdIOHandler.ReadBytes() if no data arrives in the specified time period. Otherwise it blocks indefinately waiting for data (well, Indy actually blocks indefinately, yours unblocks after 24 days). All you are really doing is creating a similar loop to the one that already exists in TIdIOHandler.ReadFromSource(), except that you are forcing the loop to wake up every 5 seconds, whereas Indy lets the OS decide when to wake up. As for the Bindings collection, how much more flexible do you want it to be? It already allow you to bind IPv4 and IPv6 sockets concurrently on the same port, if that is supported by the OS. TIdCustomTCPServer.Startup() simply adds default listening sockets if you don't specify your own bindings beforehand. If you want more control, just setup the Bindings collection yourself how you want before activating the server
mercedwang
@mercedwang
The 5-second loop is to ensure that the TCPServer will complete the Shutdown procedure in a few seconds if I set Active to False on Linux. It also fulfill the large ReadTimeout (e.g. 20 min) requirement.
mercedwang
@mercedwang
It seems that the current implementation only add IPv4 binding automatically on Linux. Because adding both v4 and v6 bindings manually is quite easy, now I think the implementation need not changing. :smile:
Remy Lebeau
@rlebeau
@mercedwang As Chad stated, closing a socket in one thread should be aborting blocked socket operations in other threads. There should be no need for such a 5-sec loop during shutdown. If the socket is waiting for bytes, the closure will abort the wait with an error, causing the reading thread to terminate (unless it doesn't handle the error correctly). As for the Bindings, read the comment above Startup(): "Linux/Unix does not allow an IPv4 socket and an IPv6 socket to listen on the same port at the same time! Windows does not have that problem..." At the time that comment was written, that behavior was tested and verified as not working. Has that changed? It certainly doesn't work on Android, which runs on top of Linux. Listening on the same port with both IPv4 and IPv6 usually requires a dual-stack socket, which Indy doesn't support yet (IndySockets/Indy#29). However, Linux has a config option (/proc/sys/net/ipv6/bindv6only) that can automatically bind an IPv4 port when binding an IPv6 port without needing separate sockets or the IPV6_V6ONLY option enabled explicitly in code.
mercedwang
@mercedwang
As you know, some Linux distributions with defects do not abort blocked socket operations, so I have to workaround this problem.
mercedwang
@mercedwang
I remember both IPv4 and v6 bindings will be added automatically on Windows when TIdTCPServer.Startup is executed, and it can accept connections of both v4 and v6 TCP clients. Doesn't it support dual stack?
mercedwang
@mercedwang
In recent Linux distributions, netstat shows that sshd binds both v4 and v6 on port 22, and Embarcadero's PAServer binds both v4 and v6 on 64211.