Hallo skyobserver,
der Fehler kommt daher, dass der genutzte Port in den FD_WAIT State geht, um dem
TCP Stack genügend Zeit zur Beendigung der Connection zu geben. Für TIdLPR und TIdRSH zwingen wir den Client dazu, sich mit einem lokalen Port in einer festen Range zu verbinden, bevor die Connection zum Server hergestellt wird. Dies ist erforderlich.
Intern passiert über die Port-Range von TIdTCPClient.BoundPortMin und .BoundPortMax.
Normalerweise, wenn man eine feste Client
IP Adresse vorgibt, wird einfach der nächste freie Port aus der Range genommen. Wenn man jetzt aber die Wildcard-
IP 0.0.0.0 nutzt (default), ist das Bind an den ursprünglichen Port erfolgreich, obwohl dieser im FD_WAIT State ist.
Das führt zum "Socket already in use" (10048). Das ist also nicht
Indy-spezifisch, sondern vom
OS.
Workaround:
- ~ 60 Sekunden warten, bis der lokale Port aus dem FD_WAIT state ist
- TIdTCPClient.BoundIP auf eine lokale
IP setzen
.BoundPort, .BoundPortMin und .BoundPortMax sollte man hingegen nur setzen, wenn man einen guten Grund hat.
Bei dem zweiten Workaround gibt es das Problem, dass ein System mehrere IPs haben kann. Dort die richtige für die Connection zum LPR Server auszuwählen erfordert dann etwas Arbeit. Die TIdTCPClient Properties sollten bei TIdLPR über die Vorfahrenklasse aber erreichbar sein.
Tut mir leid, dass es keinen einfacheren Weg gibt, das beste wäre für hochperformante Geschichten den LPR Drucker dem WinSpooler zuzuweisen, der hier automatisch die o.g. Workarounds implementiert. Also direkt gesagt: Nicht das
Rad neu erfinden
Viele Grüße,
Assertor