Hi,
@MarcMoss
I'll try to explain as best as I can. I wrote a framework (using delphi
+ ICS) that communicates with Mifare readers to allow (or deny) access
to restricted areas.
I'm using this framework with several vendors, but this one in
particular have 2 channels in the same device.
The second channel was detected as another device and not as a second
channel of the same device. I thought the code I've written was
correctly handling this case, but it turns out a had to set (and add)
another parameter(s) to change the way we handle KeepAlive. The
framework must have it's own keepalive architecture because each vendor
have a different way to "keep alive".
Anyway, as a "second device" my keepalive detected no "data travel" from
peer to server and "by design" the socket must be closed. After I modify
and improved the detection routines, all I had to do is set a framework
parameter to handle correctly the second channel of that device. Et voilá!
Hope this makes sense,
Clément
On 12/07/2018 14:17, Clément Doss wrote:
Hello!
I finally found the issue! Of course it was on my side. An invalid
parameter was resetting the idle connection "by design". I just
bypassed that parameter and the communication is working flawlessly!
Thanks for your help!
Clément
On 12/07/2018 10:07, Merijn Bosma wrote:
Do you have any software which came from the vendor which works with
this device?
If yes you can use WireShark to sniff the traffic and see what is
being sent to avoid the connection is being closed.
Merijn
On 7/12/2018 13:57, Angus Robertson - Magenta Systems Ltd wrote:
(reply from original poster)
Thanks for taking your time to help me!
I working on a device communication protocol using TCP with
TWSocketServer and TWSocket. (Delphi XE Project)
Small description: This device
Sorry don't understand what you are doing.
Is this two ICS applications talking together as client and server,
or
a physical device opening client connections to an ICS server?
It's a communication device ( Mifare reader ) in one side. On the other
side my windows service with TWSocketServer.
This device has 2 channels. The first channel connects and send initial
data that I must respond. If the communication is right then the second
channel kicks in and I must respond too. Only then the "session" is
opened and I can start sending usefull commands.
The first channel is very active and there's always some command or
status sent to my server.
The second channel on the other hand goes "idle" as soon as ended the
initial communication, and can stay like that "for hours" (according to
the vendor), but after 72 - 120 s the channels get closed and the
"close
request" is originated from "my side". Once the second channel gets
closed, the device also closes channel 1 and I must restart the
initialization protocol.
Since the close request is originating from my side, it must be either
my service or windows.
Talking to the vendor they suggested me to configure SO_KEEPALIVE on my
side. That's what i did, but still the connection closes after the same
amount of time ( 72-120s). In the log I sent, notice that the normal
communication goes from 12000 (external device port ) -> 3424 (internal
device port) or from 12000 -> 3423. After a little more than a minute
from ports 59216 ( SO port, each time that one changes ) a FIN is sent.
But it's not me (or TWSocketserver).
ICS does not have any automatic time outs, except in some of the
application servers, it's always obvious being a timer checking for
connection durations. But not in SocketServer itself.
My long experience is sockets will stay open for days. Never tried
to
use TCP KeepAlive, but from what you say it is being sent.
As suggested by the device vendor I managed to set ICS so the socket
gets configured with SO_KEEPALIVE.
20507 1164.435227 192.168.1.76 192.168.1.250 TCP 55 [TCP Keep-Alive]
12000 _ 3424 [ACK] Seq=6 Ack=17 Win=65536 Len=1
20508 1164.436457 192.168.1.250 192.168.1.76 TCP 66 [TCP Keep-Alive
ACK]
3424 _ 12000 [ACK] Seq=17 Ack=7 Win=5840 Len=0 SLE=6 SRE=7
This is happening every 30s, so I guess the configuration I did is
working. But still the connection is closed, and it's not by my
application, but it's from my side. So I guess windows is closing it. I
already deactivated my anti-virus and firewall as suggested by the
vendor support team.But still no joy.
With this particular vendor there's no "KeepAlive" command in their
protocol, and they said SO_KEEPALIVE is the way to go.
The funny thing is that channel 1 sends from time to time an IsAlive
command that I must respond. Channel 2 just keeps idle until it gets
closed.
Angus
--
*Clément G. Doss*
/Gerente de TI/
clement.d...@dhs.com.br
<mailto:%22cl%c3%a9ment+doss%22+%3cclement.d...@dhs.com.br%3E>
Signature
www.dhs.com.br <http://www.dhs.com.br/>
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
