I am using VC++ 6.0 (with SP5 installed). When using WinXP this is with SP2
installed.
I am developing an instrumentation system comprising a set of networked PCs
connected using TCP/IP TCP links. Communications on the Windows PCs use a
class derived from CAsyncSocket(). I have written client and server versions
of my software for use on the appropriate PCs.
I am also using communicating with a legacy DOS based system, with the
software written in Microsoft C V7, with 3rd party TCP/IP drivers.
In the instance where I have a problem the DOS system is running as client,
and the Windows system as server.
When I run my server side s/ware on Windows XP the connection from the DOS
system is accepted OK, but the server fails to receive any messages. It can
successfully send messages to the DOS client system. The DOS client error
detection correctly determines that the message has not been able to be
successfuly sent to the server.
By simple changing of i/p addresses / network names I have run the client
and server software on various combinations of operating system without
modifying the code behind the 'exe' files. I have also done tests with a
Windows client from another application performing a very similar
implementation of the communications of the DOS client.
If I run my client side on DOS and the server side on Windows NT, this works
perfectly.
If I run a compatible client side s/ware on Windows NT or XP and the server
side on Windows NT or XP this works perfectly.
If I run my client side on DOS and the server side on Windows XP this fails
as described as above.
Hence:
Without altering anything on the DOS client side (which communicated OK with
a WindowsNT server side) it fails to communicate with the XP server side
(which communicated OK with a WindowsXP/NT client side). The only changes
made for the test were to the ip addresses and names of the NT 'server' test
app and the XP 'client' test apps.
Does anyone know what the problem may be in trying to communicate between
systems on DOS and WindowsXP?
It should be noted that my DOS app communicates successfully using tcp/ip
with other non PC based equipment.
9  2339 
On Tue, 17 Apr 2007 00:28:01 -0700, Howard Smith
<Ho*********@discussions.microsoft.comwrote:
>I am using VC++ 6.0 (with SP5 installed). When using WinXP this is with SP2
installed.
I am developing an instrumentation system comprising a set of networked PCs
connected using TCP/IP TCP links. Communications on the Windows PCs use a
class derived from CAsyncSocket(). I have written client and server versions
of my software for use on the appropriate PCs.
I am also using communicating with a legacy DOS based system, with the
software written in Microsoft C V7, with 3rd party TCP/IP drivers.
In the instance where I have a problem the DOS system is running as client,
and the Windows system as server.
When I run my server side s/ware on Windows XP the connection from the DOS
system is accepted OK, but the server fails to receive any messages. It can
successfully send messages to the DOS client system. The DOS client error
detection correctly determines that the message has not been able to be
successfuly sent to the server.
By simple changing of i/p addresses / network names I have run the client
and server software on various combinations of operating system without
modifying the code behind the 'exe' files. I have also done tests with a
Windows client from another application performing a very similar
implementation of the communications of the DOS client.
If I run my client side on DOS and the server side on Windows NT, this works
perfectly.
If I run a compatible client side s/ware on Windows NT or XP and the server
side on Windows NT or XP this works perfectly.
If I run my client side on DOS and the server side on Windows XP this fails
as described as above.
Hence:
Without altering anything on the DOS client side (which communicated OK with
a WindowsNT server side) it fails to communicate with the XP server side
(which communicated OK with a WindowsXP/NT client side). The only changes
made for the test were to the ip addresses and names of the NT 'server' test
app and the XP 'client' test apps.
Does anyone know what the problem may be in trying to communicate between
systems on DOS and WindowsXP?
It should be noted that my DOS app communicates successfully using tcp/ip
with other non PC based equipment.
Working through your problems with a packet sniffer will let you see
just what message exchanges are going on between your systems. You
also don't give much information about what it means for the system to
"fail". Just what function fails and exactly what error codes are
returned? Exactly at what point in the entire communication system
does it fail? Saying merely that "the message failed to be delivered"
doesn't provide much information.
Maybe I can't help too much, but I can sympathize with you enormously.
I, too, have long hours of bitter experience trying to get various
systems to intercommunicate. Often the only solution I have found is,
as suggested above, to put some kind of monitor on the communication
line to see every bit and byte of data that gets sent by whom and,
often, at exactly what time.
On Apr 17, 9:28 am, Howard Smith
<HowardSm...@discussions.microsoft.comwrote:
I am using VC++ 6.0 (with SP5 installed). When using WinXP this is with SP2
installed.
I am developing an instrumentation system comprising a set of networked PCs
connected using TCP/IP TCP links. Communications on the Windows PCs use a
class derived from CAsyncSocket(). I have written client and server versions
of my software for use on the appropriate PCs.
I am also using communicating with a legacy DOS based system, with the
software written in Microsoft C V7, with 3rd party TCP/IP drivers.
In the instance where I have a problem the DOS system is running as client,
and the Windows system as server.
When I run my server side s/ware on Windows XP the connection from the DOS
system is accepted OK, but the server fails to receive any messages. It can
successfully send messages to the DOS client system. The DOS client error
detection correctly determines that the message has not been able to be
successfuly sent to the server.
<snip>
Use a network sniffer (such as WireShark) to check what happens "on
the wire" on the server side.
Arnaud
MVP - VC
"Howard Smith" <Ho*********@discussions.microsoft.comwrote in message
news:AF**********************************@microsof t.com...
>I am using VC++ 6.0 (with SP5 installed). When using WinXP this is with SP2
installed.
I am developing an instrumentation system comprising a set of networked
PCs
connected using TCP/IP TCP links. Communications on the Windows PCs use a
class derived from CAsyncSocket(). I have written client and server
versions
of my software for use on the appropriate PCs.
I am also using communicating with a legacy DOS based system, with the
software written in Microsoft C V7, with 3rd party TCP/IP drivers.
In the instance where I have a problem the DOS system is running as
client,
and the Windows system as server.
When I run my server side s/ware on Windows XP the connection from the DOS
system is accepted OK, but the server fails to receive any messages. It
can
successfully send messages to the DOS client system. The DOS client error
detection correctly determines that the message has not been able to be
successfuly sent to the server.
By simple changing of i/p addresses / network names I have run the client
and server software on various combinations of operating system without
modifying the code behind the 'exe' files. I have also done tests with a
Windows client from another application performing a very similar
implementation of the communications of the DOS client.
If I run my client side on DOS and the server side on Windows NT, this
works
perfectly.
If I run a compatible client side s/ware on Windows NT or XP and the
server
side on Windows NT or XP this works perfectly.
If I run my client side on DOS and the server side on Windows XP this
fails
as described as above.
Hence:
Without altering anything on the DOS client side (which communicated OK
with
a WindowsNT server side) it fails to communicate with the XP server side
(which communicated OK with a WindowsXP/NT client side). The only changes
made for the test were to the ip addresses and names of the NT 'server'
test
app and the XP 'client' test apps.
Does anyone know what the problem may be in trying to communicate between
systems on DOS and WindowsXP?
At a guess, you've used a C structure for your message, with different
compilers (one 16-bit and one 32-bit) so the layouts are incompatible. Make
sure you are passing the exact same size to send() and recv() in both
environments.
It should be noted that my DOS app communicates successfully using tcp/ip
with other non PC based equipment.
"r norman" wrote:
On Tue, 17 Apr 2007 00:28:01 -0700, Howard Smith
<Ho*********@discussions.microsoft.comwrote:
I am using VC++ 6.0 (with SP5 installed). When using WinXP this is with SP2
installed.
I am developing an instrumentation system comprising a set of networked PCs
connected using TCP/IP TCP links. Communications on the Windows PCs use a
class derived from CAsyncSocket(). I have written client and server versions
of my software for use on the appropriate PCs.
I am also using communicating with a legacy DOS based system, with the
software written in Microsoft C V7, with 3rd party TCP/IP drivers.
In the instance where I have a problem the DOS system is running as client,
and the Windows system as server.
When I run my server side s/ware on Windows XP the connection from the DOS
system is accepted OK, but the server fails to receive any messages. It can
successfully send messages to the DOS client system. The DOS client error
detection correctly determines that the message has not been able to be
successfuly sent to the server.
By simple changing of i/p addresses / network names I have run the client
and server software on various combinations of operating system without
modifying the code behind the 'exe' files. I have also done tests with a
Windows client from another application performing a very similar
implementation of the communications of the DOS client.
If I run my client side on DOS and the server side on Windows NT, this works
perfectly.
If I run a compatible client side s/ware on Windows NT or XP and the server
side on Windows NT or XP this works perfectly.
If I run my client side on DOS and the server side on Windows XP this fails
as described as above.
Hence:
Without altering anything on the DOS client side (which communicated OK with
a WindowsNT server side) it fails to communicate with the XP server side
(which communicated OK with a WindowsXP/NT client side). The only changes
made for the test were to the ip addresses and names of the NT 'server' test
app and the XP 'client' test apps.
Does anyone know what the problem may be in trying to communicate between
systems on DOS and WindowsXP?
It should be noted that my DOS app communicates successfully using tcp/ip
with other non PC based equipment.
Working through your problems with a packet sniffer will let you see
just what message exchanges are going on between your systems. You
also don't give much information about what it means for the system to
"fail". Just what function fails and exactly what error codes are
returned? Exactly at what point in the entire communication system
does it fail? Saying merely that "the message failed to be delivered"
doesn't provide much information.
Maybe I can't help too much, but I can sympathize with you enormously.
I, too, have long hours of bitter experience trying to get various
systems to intercommunicate. Often the only solution I have found is,
as suggested above, to put some kind of monitor on the communication
line to see every bit and byte of data that gets sent by whom and,
often, at exactly what time.
The effect I see is that in my VC++ program OnReceive() doesn't get called
even though a Send() is executed by the DOS program. As a result my VC++
program doesn't set the flag that causes my program to then do a Recive() to
get the message. In case it was OnReceive() not working properly I tried
using a key press to set the flag when I knew the DOS program had done a
send. In this case Receive() returned no data, effectively confirming that
indeed nothing had apparently been received.
At the DOS end an asynchronous Send is triggered. A second call to Send then
returns an error indicating that the previous send has not yet completed.
This agrees with the message not getting received by my VC++ program. Of
course it doesn't explain why and which end is at fault.
I can send messages successfully the other way (from VC++ to the DOS app),
so the socket must have been established OK.
The logic etc. in both my programs is presumably basically correct as they
work when the 'other end' is on an O/S combination that works OK. e.g.
DOS->NT or XP->NT. I
I'll try to find the sniffer I came across a few years ago, though my
understanding of very low level TCP/IP is limited so I'm not sure what it
will tell me. I expect the OS to do that for me! I suspect I'll need to find
an ethernet hub rather that an ethernet switch too - which could be more of a
challenge - may need to visit a museum.
On Thu, 19 Apr 2007 08:06:04 -0700, Howard Smith
<Ho*********@discussions.microsoft.comwrote:
>
"r norman" wrote:
>On Tue, 17 Apr 2007 00:28:01 -0700, Howard Smith
<Ho*********@discussions.microsoft.comwrote:
>I am using VC++ 6.0 (with SP5 installed). When using WinXP this is with SP2
installed.
I am developing an instrumentation system comprising a set of networked PCs
connected using TCP/IP TCP links. Communications on the Windows PCs use a
class derived from CAsyncSocket(). I have written client and server versions
of my software for use on the appropriate PCs.
I am also using communicating with a legacy DOS based system, with the
software written in Microsoft C V7, with 3rd party TCP/IP drivers.
In the instance where I have a problem the DOS system is running as client,
and the Windows system as server.
When I run my server side s/ware on Windows XP the connection from the DOS
system is accepted OK, but the server fails to receive any messages. It can
successfully send messages to the DOS client system. The DOS client error
detection correctly determines that the message has not been able to be
successfuly sent to the server.
By simple changing of i/p addresses / network names I have run the client
and server software on various combinations of operating system without
modifying the code behind the 'exe' files. I have also done tests with a
Windows client from another application performing a very similar
implementation of the communications of the DOS client.
If I run my client side on DOS and the server side on Windows NT, this works
perfectly.
If I run a compatible client side s/ware on Windows NT or XP and the server
side on Windows NT or XP this works perfectly.
If I run my client side on DOS and the server side on Windows XP this fails
as described as above.
Hence:
Without altering anything on the DOS client side (which communicated OK with
a WindowsNT server side) it fails to communicate with the XP server side
(which communicated OK with a WindowsXP/NT client side). The only changes
made for the test were to the ip addresses and names of the NT 'server' test
app and the XP 'client' test apps.
Does anyone know what the problem may be in trying to communicate between
systems on DOS and WindowsXP?
It should be noted that my DOS app communicates successfully using tcp/ip
with other non PC based equipment.
Working through your problems with a packet sniffer will let you see
just what message exchanges are going on between your systems. You
also don't give much information about what it means for the system to
"fail". Just what function fails and exactly what error codes are
returned? Exactly at what point in the entire communication system
does it fail? Saying merely that "the message failed to be delivered"
doesn't provide much information.
Maybe I can't help too much, but I can sympathize with you enormously.
I, too, have long hours of bitter experience trying to get various
systems to intercommunicate. Often the only solution I have found is,
as suggested above, to put some kind of monitor on the communication
line to see every bit and byte of data that gets sent by whom and,
often, at exactly what time.
The effect I see is that in my VC++ program OnReceive() doesn't get called
even though a Send() is executed by the DOS program. As a result my VC++
program doesn't set the flag that causes my program to then do a Recive() to
get the message. In case it was OnReceive() not working properly I tried
using a key press to set the flag when I knew the DOS program had done a
send. In this case Receive() returned no data, effectively confirming that
indeed nothing had apparently been received.
At the DOS end an asynchronous Send is triggered. A second call to Send then
returns an error indicating that the previous send has not yet completed.
This agrees with the message not getting received by my VC++ program. Of
course it doesn't explain why and which end is at fault.
I can send messages successfully the other way (from VC++ to the DOS app),
so the socket must have been established OK.
The logic etc. in both my programs is presumably basically correct as they
work when the 'other end' is on an O/S combination that works OK. e.g.
DOS->NT or XP->NT. I
I'll try to find the sniffer I came across a few years ago, though my
understanding of very low level TCP/IP is limited so I'm not sure what it
will tell me. I expect the OS to do that for me! I suspect I'll need to find
an ethernet hub rather that an ethernet switch too - which could be more of a
challenge - may need to visit a museum.
I am afraid you will have to learn to use the sniffer or network
monitor. That way you can see just what happens when your DOS
program does a Send(). You also have to look carefully at the return
values for all functions when you establish the connection. Just
because you can receive data does not mean the socket is properly
established for sending. Doesn't the socket return some error code
on failure that you can interpret? You could also have a problem in
some other area -- switching systems around could mean changing TCP/IP
setup values and mis-setting things like DNS server address and masks.
"r norman" wrote:
On Thu, 19 Apr 2007 08:06:04 -0700, Howard Smith
<Ho*********@discussions.microsoft.comwrote:
"r norman" wrote:
On Tue, 17 Apr 2007 00:28:01 -0700, Howard Smith
<Ho*********@discussions.microsoft.comwrote:
I am using VC++ 6.0 (with SP5 installed). When using WinXP this is with SP2
installed.
I am developing an instrumentation system comprising a set of networked PCs
connected using TCP/IP TCP links. Communications on the Windows PCs use a
class derived from CAsyncSocket(). I have written client and server versions
of my software for use on the appropriate PCs.
I am also using communicating with a legacy DOS based system, with the
software written in Microsoft C V7, with 3rd party TCP/IP drivers.
In the instance where I have a problem the DOS system is running as client,
and the Windows system as server.
When I run my server side s/ware on Windows XP the connection from the DOS
system is accepted OK, but the server fails to receive any messages. It can
successfully send messages to the DOS client system. The DOS client error
detection correctly determines that the message has not been able to be
successfuly sent to the server.
By simple changing of i/p addresses / network names I have run the client
and server software on various combinations of operating system without
modifying the code behind the 'exe' files. I have also done tests with a
Windows client from another application performing a very similar
implementation of the communications of the DOS client.
If I run my client side on DOS and the server side on Windows NT, this works
perfectly.
If I run a compatible client side s/ware on Windows NT or XP and the server
side on Windows NT or XP this works perfectly.
If I run my client side on DOS and the server side on Windows XP this fails
as described as above.
Hence:
Without altering anything on the DOS client side (which communicated OK with
a WindowsNT server side) it fails to communicate with the XP server side
(which communicated OK with a WindowsXP/NT client side). The only changes
made for the test were to the ip addresses and names of the NT 'server' test
app and the XP 'client' test apps.
Does anyone know what the problem may be in trying to communicate between
systems on DOS and WindowsXP?
It should be noted that my DOS app communicates successfully using tcp/ip
with other non PC based equipment.
Working through your problems with a packet sniffer will let you see
just what message exchanges are going on between your systems. You
also don't give much information about what it means for the system to
"fail". Just what function fails and exactly what error codes are
returned? Exactly at what point in the entire communication system
does it fail? Saying merely that "the message failed to be delivered"
doesn't provide much information.
Maybe I can't help too much, but I can sympathize with you enormously.
I, too, have long hours of bitter experience trying to get various
systems to intercommunicate. Often the only solution I have found is,
as suggested above, to put some kind of monitor on the communication
line to see every bit and byte of data that gets sent by whom and,
often, at exactly what time.
The effect I see is that in my VC++ program OnReceive() doesn't get called
even though a Send() is executed by the DOS program. As a result my VC++
program doesn't set the flag that causes my program to then do a Recive() to
get the message. In case it was OnReceive() not working properly I tried
using a key press to set the flag when I knew the DOS program had done a
send. In this case Receive() returned no data, effectively confirming that
indeed nothing had apparently been received.
At the DOS end an asynchronous Send is triggered. A second call to Send then
returns an error indicating that the previous send has not yet completed.
This agrees with the message not getting received by my VC++ program. Of
course it doesn't explain why and which end is at fault.
I can send messages successfully the other way (from VC++ to the DOS app),
so the socket must have been established OK.
The logic etc. in both my programs is presumably basically correct as they
work when the 'other end' is on an O/S combination that works OK. e.g.
DOS->NT or XP->NT. I
I'll try to find the sniffer I came across a few years ago, though my
understanding of very low level TCP/IP is limited so I'm not sure what it
will tell me. I expect the OS to do that for me! I suspect I'll need to find
an ethernet hub rather that an ethernet switch too - which could be more of a
challenge - may need to visit a museum.
I am afraid you will have to learn to use the sniffer or network
monitor. That way you can see just what happens when your DOS
program does a Send(). You also have to look carefully at the return
values for all functions when you establish the connection. Just
because you can receive data does not mean the socket is properly
established for sending. Doesn't the socket return some error code
on failure that you can interpret? You could also have a problem in
some other area -- switching systems around could mean changing TCP/IP
setup values and mis-setting things like DNS server address and masks.
>
I obtained a sniffer and have used it to identify the problem. By comparing working and non-working scenarios I noted that the available receive buffer space notified in the tcp/ip packets is around 64K from XP, but much lower e.g. <=16K for NT. I suspect that the legacy DOS TCP/IP package I am using is not correctly interpreting buffer available space when >16K and is perhaps treating this as zero or negative, hence is not attempting to transmit.
I have tried using SetSockOpt() in my code to set SO_RCVBUF to <16K for the
socket I am using. However this does not seem to work. An initial call to
GetSockOpt() is not reporting the same as I am seeing with the sniffer, and
though I use SetSockOpt() to set a different value which a subsequent
GetSockOpt() demonstrates has been set, the buffer space shown by the sniffer
remains unchanged - hence the DOS TCP/IP is still not able to transmit.
The only way I have been able to get successful communications is to force
the XP network card to operate at 10Mb/s rather than the default auto which
results in 100Mb/s. This seems to have the side effect of reducing the
announced buffer space. This is not ideal, but it does at least work though.
This has now allowed me at least to progress, though this has revealed
another unexpected problem. I plan to use 2 ethernet cards, one for a small
isolated network for comms with the set of computers running my specialised
system, and one for wider external comms on our main network for file / print
servers etc. When I plug the 'external' network cable into the 2nd card
communications stops on the original card. It carries on working if I plug
the external cable into the local hub on the other card's network. Is there
some odd problem with having 2 ethernet cards? I've used 2 cards of different
types in the past to enable a PC to access ethernet and token ring
simultaneously OK.
>
On Tue, 1 May 2007 00:55:00 -0700, Howard Smith
<Ho*********@discussions.microsoft.comwrote:
>
"r norman" wrote:
>On Thu, 19 Apr 2007 08:06:04 -0700, Howard Smith
<Ho*********@discussions.microsoft.comwrote:
>
"r norman" wrote:
On Tue, 17 Apr 2007 00:28:01 -0700, Howard Smith
<Ho*********@discussions.microsoft.comwrote:
I am using VC++ 6.0 (with SP5 installed). When using WinXP this is with SP2
installed.
I am developing an instrumentation system comprising a set of networked PCs
connected using TCP/IP TCP links. Communications on the Windows PCs use a
class derived from CAsyncSocket(). I have written client and server versions
of my software for use on the appropriate PCs.
I am also using communicating with a legacy DOS based system, with the
software written in Microsoft C V7, with 3rd party TCP/IP drivers.
In the instance where I have a problem the DOS system is running as client,
and the Windows system as server.
When I run my server side s/ware on Windows XP the connection from the DOS
system is accepted OK, but the server fails to receive any messages. It can
successfully send messages to the DOS client system. The DOS client error
detection correctly determines that the message has not been able to be
successfuly sent to the server.
By simple changing of i/p addresses / network names I have run the client
and server software on various combinations of operating system without
modifying the code behind the 'exe' files. I have also done tests with a
Windows client from another application performing a very similar
implementation of the communications of the DOS client.
If I run my client side on DOS and the server side on Windows NT, this works
perfectly.
If I run a compatible client side s/ware on Windows NT or XP and the server
side on Windows NT or XP this works perfectly.
If I run my client side on DOS and the server side on Windows XP this fails
as described as above.
Hence:
Without altering anything on the DOS client side (which communicated OK with
a WindowsNT server side) it fails to communicate with the XP server side
(which communicated OK with a WindowsXP/NT client side). The only changes
made for the test were to the ip addresses and names of the NT 'server' test
app and the XP 'client' test apps.
Does anyone know what the problem may be in trying to communicate between
systems on DOS and WindowsXP?
It should be noted that my DOS app communicates successfully using tcp/ip
with other non PC based equipment.
Working through your problems with a packet sniffer will let you see
just what message exchanges are going on between your systems. You
also don't give much information about what it means for the system to
"fail". Just what function fails and exactly what error codes are
returned? Exactly at what point in the entire communication system
does it fail? Saying merely that "the message failed to be delivered"
doesn't provide much information.
Maybe I can't help too much, but I can sympathize with you enormously.
I, too, have long hours of bitter experience trying to get various
systems to intercommunicate. Often the only solution I have found is,
as suggested above, to put some kind of monitor on the communication
line to see every bit and byte of data that gets sent by whom and,
often, at exactly what time.
The effect I see is that in my VC++ program OnReceive() doesn't get called
even though a Send() is executed by the DOS program. As a result my VC++
program doesn't set the flag that causes my program to then do a Recive() to
get the message. In case it was OnReceive() not working properly I tried
using a key press to set the flag when I knew the DOS program had done a
send. In this case Receive() returned no data, effectively confirming that
indeed nothing had apparently been received.
At the DOS end an asynchronous Send is triggered. A second call to Send then
returns an error indicating that the previous send has not yet completed.
This agrees with the message not getting received by my VC++ program. Of
course it doesn't explain why and which end is at fault.
I can send messages successfully the other way (from VC++ to the DOS app),
so the socket must have been established OK.
The logic etc. in both my programs is presumably basically correct as they
work when the 'other end' is on an O/S combination that works OK. e.g.
DOS->NT or XP->NT. I
I'll try to find the sniffer I came across a few years ago, though my
understanding of very low level TCP/IP is limited so I'm not sure what it
will tell me. I expect the OS to do that for me! I suspect I'll need to find
an ethernet hub rather that an ethernet switch too - which could be more of a
challenge - may need to visit a museum.
I am afraid you will have to learn to use the sniffer or network
monitor. That way you can see just what happens when your DOS
program does a Send(). You also have to look carefully at the return
values for all functions when you establish the connection. Just
because you can receive data does not mean the socket is properly
established for sending. Doesn't the socket return some error code
on failure that you can interpret? You could also have a problem in
some other area -- switching systems around could mean changing TCP/IP
setup values and mis-setting things like DNS server address and masks.
>>
I obtained a sniffer and have used it to identify the problem. By comparing working and non-working scenarios I noted that the available receive buffer space notified in the tcp/ip packets is around 64K from XP, but much lower e.g. <=16K for NT. I suspect that the legacy DOS TCP/IP package I am using is not correctly interpreting buffer available space when >16K and is perhaps treating this as zero or negative, hence is not attempting to transmit.
I have tried using SetSockOpt() in my code to set SO_RCVBUF to <16K for the
socket I am using. However this does not seem to work. An initial call to
GetSockOpt() is not reporting the same as I am seeing with the sniffer, and
though I use SetSockOpt() to set a different value which a subsequent
GetSockOpt() demonstrates has been set, the buffer space shown by the sniffer
remains unchanged - hence the DOS TCP/IP is still not able to transmit.
The only way I have been able to get successful communications is to force
the XP network card to operate at 10Mb/s rather than the default auto which
results in 100Mb/s. This seems to have the side effect of reducing the
announced buffer space. This is not ideal, but it does at least work though.
This has now allowed me at least to progress, though this has revealed
another unexpected problem. I plan to use 2 ethernet cards, one for a small
isolated network for comms with the set of computers running my specialised
system, and one for wider external comms on our main network for file / print
servers etc. When I plug the 'external' network cable into the 2nd card
communications stops on the original card. It carries on working if I plug
the external cable into the local hub on the other card's network. Is there
some odd problem with having 2 ethernet cards? I've used 2 cards of different
types in the past to enable a PC to access ethernet and token ring
simultaneously OK.
I seem to recall problems with buffer size back a number of years ago
but I can't recall at all how I solved it. I think it was setting the
buffer size in the Windows system through the registry. See, for
example, http://rdweb.cns.vt.edu/public/notes/win2k-tcpip.htm
Obviously a DOS system can't handle anything bigger than 64K and it is
indeed possible that a value greater than 32K is misinterpreted.
There is indeed something odd about using several network cards in one
system to get everything to work properly but I am afraid that I don't
understand network communications sufficiently (or at all, for that
matter!) to help you properly with either this problem or the buffer
size problem. My impression is that if the two network cards have
different network IP addresses not within the range of the subnet mask
of each other and you try to connect to an outside system within the
subnet range of either card, then your operating system knows which
card to use. If the IP address is totally different, then I have no
idea how the operating system figures out which one to use. I have
had problems switching connections between different network
connections. There are various caches maintained by the operating
system to indicate how connections can best be maintained and when I
have problems I have to run around looking up reference books to find
out just what the caches are, how to access them, and how to clear
them. After I do this, it all seems to work. But you need somebody
experienced and knowledgeable in what is happening. When they answer
you, I will be sure to carefully read the solution and this time print
it out and paste it on the wall above my work area so I can find it
next time I need it!
Perhaps a better place to find out about how to solve the problems
described in TCP/IP communication between systems (which I have
snipped out) would be on microsoft.public.win32.programmer.networks.
Ask there, including the information on buffer size and multiple
hosted systems.
>I obtained a sniffer and have used it to identify the problem. By
comparing working and non-working scenarios I noted that the available
receive buffer space notified in the tcp/ip packets is around 64K from
XP, but much lower e.g. <=16K for NT. I suspect that the legacy DOS
TCP/IP package I am using is not correctly interpreting buffer available
space when >16K and is perhaps treating this as zero or negative, hence
is not attempting to transmit.
I have tried using SetSockOpt() in my code to set SO_RCVBUF to <16K for
the
socket I am using. However this does not seem to work. An initial call to
GetSockOpt() is not reporting the same as I am seeing with the sniffer,
and
though I use SetSockOpt() to set a different value which a subsequent
GetSockOpt() demonstrates has been set, the buffer space shown by the
sniffer
remains unchanged - hence the DOS TCP/IP is still not able to transmit.
The only way I have been able to get successful communications is to force
the XP network card to operate at 10Mb/s rather than the default auto
which
results in 100Mb/s. This seems to have the side effect of reducing the
announced buffer space. This is not ideal, but it does at least work
though.
I believe that advertising an MSS (maximum segment size) or recvwnd (receive
window) that large requires an extension in the IP header. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: invinfo |
last post by:
After having MySQL 3.23 installed, I upgraded to 5.0, but having
problems with the service. I did not do a full uninstall and its not
clear, if I should have or not.
However as many Windows...
|
by: Scott |
last post by:
I have an application written in C# using VS 2003 with MSDE as the database.
The reports use Crystal as provided with VS. The application and reports
work correctly under WinXP, but the reports do...
|
by: andrew_webby at hotmail |
last post by:
Hi
Am having a problem with an app I wrote to test patch delivery. I
contact a remote PC, and get it to run a patch which is installed on a
server. It works fine if I use psexec for example and...
|
by: Rayearth |
last post by:
Hi all
I'm having problems with using anchors to automatically resize controls in
runtime with VB.net. In my development environment, I run Win2k and all the
anchoring works fine, but once I...
|
by: BARTKO, Zoltán |
last post by:
Hello, folks,
I am trying to install pgsql8 on winxp. I tried first to install "as
is" with pginstaller beta2-dev3, no luck, it froze, switched off
Nod32, froze a little later, ran through the...
|
by: cmills28 |
last post by:
Hi.
I'm developing a php 4.3.10 script, extracting data from webpages.
Using string functions (strpos, substr) alot, some arrays (both static
& dynamic) also data is going to a MySQL 5 DB. Am...
|
by: Fraggle69 |
last post by:
Hi,
Does anyone have any idea of how I can use Python to get images from my
firewire camera??
I am using python under winXP pro....
Cheers
Fraggle
|
by: Newbie |
last post by:
Hi All
Trying to create a mini-ASP web dev with a couple of PCs at school. When
the teachers are happy with the site on the LAN then going to upload it to
the school site. Problem is having...
|
by: Kevin |
last post by:
I would appreciate it if anyone could help or advise on coding for comms.
I am using C# and need to be able to open a comms port, send a command to a
device, receive the data back and close the...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 2 August 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM)
The start time is equivalent to 19:00 (7PM) in Central...
|
by: erikbower65 |
last post by:
Using CodiumAI's pr-agent is simple and powerful. Follow these steps:
1. Install CodiumAI CLI: Ensure Node.js is installed, then run 'npm install -g codiumai' in the terminal.
2. Connect to...
|
by: linyimin |
last post by:
Spring Startup Analyzer generates an interactive Spring application startup report that lets you understand what contributes to the application startup time and helps to optimize it. Support for...
|
by: erikbower65 |
last post by:
Here's a concise step-by-step guide for manually installing IntelliJ IDEA:
1. Download: Visit the official JetBrains website and download the IntelliJ IDEA Community or Ultimate edition based on...
|
by: kcodez |
last post by:
As a H5 game development enthusiast, I recently wrote a very interesting little game - Toy Claw ((http://claw.kjeek.com/))。Here I will summarize and share the development experience here, and hope it...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Sept 2023 starting at 18:00 UK time (6PM UTC+1) and finishing at about 19:15 (7.15PM)
The start time is equivalent to 19:00 (7PM) in Central...
|
by: Taofi |
last post by:
I try to insert a new record but the error message says the number of query names and destination fields are not the same
This are my field names
ID, Budgeted, Actual, Status and Differences
...
|
by: DJRhino1175 |
last post by:
When I run this code I get an error, its Run-time error# 424 Object required...This is my first attempt at doing something like this. I test the entire code and it worked until I added this -
If...
|
by: Rina0 |
last post by:
I am looking for a Python code to find the longest common subsequence of two strings. I found this blog post that describes the length of longest common subsequence problem and provides a solution in...
| |
