data source with non blocking TCP/IP

[bkelly]

Hello All,
I am working on a application that sends data to the CDS server via
TCP/IP. I have the IadsDS demo program but the class it uses runs in
blocking mode. When I have a code problem (as in testing and
debugging my code) or the connection is lost, the program hangs on a
TCP call and ther user cannot determine the status. Does anyone have
a class or some code that I can use to send data to the IADS server
with non-blocking calls? To my knowledge, that would enable the use
of a text box in the dialog to keep the user advised of the
situation. I don’t have the experience to write that from scratch.

The environment is Windows XP, Visual Studio 2008, CPP, MFC. The
environment is a bit specific as I use a starter application that came
with our Wyle G2 and Omega Serve.

Thank you

[Adam Chant]

If you are having problems with debugging the data source due to the
timeouts that are being triggered by the CDS, you can disable the timeout by
adding the following to the startup file.

DATA_SOURCE_READ_TIMEOUT_IN_MILLISECONDS 0

Adam Chant
Symvionics, Inc.
IADS Application Engineer
(661) 273-7003 x 210

Thank you

--
You received this message because you are subscribed to the Google Groups
"IADS" group.
To post to this group, send email to ia...@googlegroups.com.
To unsubscribe from this group, send email to
iads+uns...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/iads?hl=en.

[bkelly]

I tried a value of 0 and of 60000 both to no avail.
This may work for the relatively simple test utility IadsDS, but not
so well for a more involved application.
When the application gets hung on a call the debugger does show me
where the code is hung. I can add breakpoints just before the send
call, but then I keep getting errors. For example, in my application
the send for frame type produces an error if I pause on or after the
send for endian type. The debugger cannot kill the program. I must
stop CDS then restart it so it will reply to a post thus freeing my
application.

I recognize that this may be due to my lack of knowledge in setting up
my environment, that is the way I am working now.
I strongly prefer to have the TCP/IP code in a non-blocking mode That
way a message can be put in the dialog box informing me and the future
users as to what must be done.

On Nov 16, 6:15 pm, "Adam Chant" <a...@iads-soft.com> wrote:
> If you are having problems with debugging the data source due to the
> timeouts that are being triggered by the CDS, you can disable the timeout by
> adding the following to the startup file.
>
> DATA_SOURCE_READ_TIMEOUT_IN_MILLISECONDS 0
>
> Adam Chant
> Symvionics, Inc.
> IADS Application Engineer
> (661) 273-7003 x 210
>

<snip>

[Mike Burt]

Hi Bryan:

Believe what you are seeing here is that during the handshake protocol
that occurs during the initial connection that includes passing byte
order information the IADS server (CDS) is timing out when waiting to
receive the next expected message due to the delay incurred from
stepping through the code on your end. At this point in the protocol
the IADS server disconnects the current socket and attempts to
reconnect on a new socket...but at this same time frame you are still
trying to continue under the protocol flow you are currently under so
this creates a situation where the two sides are essentially out of
sync. Until you go back into an accept mode on your end the IADS
server will never successfully reconnect. You can set the socket on
your end to be non-blocking via the ioctlsocket call when creating the
socket but not sure how this would resolve the issue...would still
need to resynchronize with the state of the socket on the IADS server.

There are output messages on the CDS console window that specify
socket disconnect and timeout behaviors that may assist in verifying
what is happening.

Disabling the timeout should resolve the situation but based on your
description sounds like the timeout is not being successfully disabled
as expected...thinking that you are either launching the IADS server
directly without the use of an Op Console (so the syntax on the
startup file entry may be incorrect) or you are placing the new entry
in the wrong location within the Op Console startup file. If the
former is true...please try adding the following to the CDS startup
file and see if that makes a difference:

DATA_SOURCE_READ_TIMEOUT_IN_MILLISECONDS = 0

If you are using an Op Console make sure the following entry is in the
CDS section of the Op Console startup file:

DATA_SOURCE_READ_TIMEOUT_IN_MILLISECONDS 0

If the above assumptions are incorrect please clarify...otherwise if
you continue to have problems please let us know.

Thanks

[bkelly]

On Nov 17, 3:55 pm, Mike Burt <mb...@iads-soft.com> wrote:
> Hi Bryan:
>
> Believe what you are seeing here is that during the handshake protocol
> that occurs during the initial connection that includes passing byte
> order information the IADS server (CDS) is timing out when waiting to
> receive the next expected message due to the delay incurred from
> stepping through the code on your end.

What I am seeing is that CDS breaks the connection. After the initial
connect the server breaks the connection forcing the data source to
start over when the server initiates data gathering. After adding
some additional console prints to program IadsDS, the output indicates
this:
DS for Data Source, CDS for computer Data Server, line numbers are
from adding __LINE__ in some of the outputs so there is no doubt as to
the origin of the text.
DS: Starts and outputs
Blocked, wait connect by CDS line 318
CDS: Start Opconsole
DS: Send Endian
Send Frame
Start Data Transffer
SendData returned false line 377
CDS terminated connection ...
Blocked, wait connect by CDS line 318
CDS Start Data gather
DS Send Endian
Send Frame
Start data transfer

This requires my soruce code to have the ability to detect the broken
connection and start over. I was not expecting the CDS to terminate
the connection after initial communications with the data source.
After adding code to check for lost connection and restart I have made
some progress.

>
> There are output messages on the CDS console window that specify
> socket disconnect and timeout behaviors that may assist in verifying
> what is happening.

I have looked but not discovered any display in the CDS console
window.

Still, when there is a problem, the source application code hangs on
the line of code waiting for completion. The debugger shows the code
running and cannot show that it is blocked on a TCP/IP operation.
Often the code cannot be halted with the debugger. I have had to
restart CDS just to get it to re-establish the connection so the
application can be stopped.

This will be much easier if the application is written with non-
blocking TCP calls.

[Michael Jones]

In your datasource, you are seeing the effect of the CDS performing the Connect Test option (as directed by the OpConsole).

In essence, the datasource application needs to be prepared for the CDS to disconnect and/or reconnect at any time.

Presuming you are running Visual Studio, you should always be able to force a break in the application. After making the debugger the active application hit Ctrl-Alt-Break.  The Thread and Call Stack windows are important to figure out where you are at this point.

Similarly; Shift-F5 (Debug->Stop Debugging) should abort the running application when in the debugger.

[Mike Burt]

Bryan:

A little confused here...are you using the IadsDS project with
modifications? If so that should have already contained the
infrastructure to handle reconnecting after the connect test.

If the application is in a hung state after the 2nd 'Start Data
Transfer' instance as stated in the DS/CDS output flow...speculating
that you may have a mismatch between the advertised size of the packet
(i.e. 1st field in the packet) and the actual size of the
packet...sounds as if the IADS server may be waiting on some expected
remaining contents of the packet to be sent...are you breaking up a
single packet into multiple sends?

Please let us know what you find.