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  2413 
On Tue, 17 Apr 2007 00:28:01 -0700, Howard Smith
<Ho*********@di scussions.micro soft.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
implementati on 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 intercommunicat e. 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...@di scussions.micro soft.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*********@di scussions.micro soft.comwrote in message
news:AF******** *************** ***********@mic rosoft.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*********@di scussions.micro soft.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 intercommunicat e. 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*********@di scussions.micro soft.comwrote:
>
"r norman" wrote:
>On Tue, 17 Apr 2007 00:28:01 -0700, Howard Smith
<Ho*********@d iscussions.micr osoft.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
implementati on 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 intercommunicat e. 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
understandin g 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*********@di scussions.micro soft.comwrote:
"r norman" wrote:
On Tue, 17 Apr 2007 00:28:01 -0700, Howard Smith
<Ho*********@di scussions.micro soft.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 intercommunicat e. 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*********@di scussions.micro soft.comwrote:
>
"r norman" wrote:
>On Thu, 19 Apr 2007 08:06:04 -0700, Howard Smith
<Ho*********@d iscussions.micr osoft.comwrote:
>
"r norman" wrote:
On Tue, 17 Apr 2007 00:28:01 -0700, Howard Smith
<Ho*********@d iscussions.micr osoft.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
implementati on 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 intercommunicat e. 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
understandin g 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
communicatio ns 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
simultaneous ly 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.publi c.win32.program mer.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 (WinXP) users know, the existing service needs
to be modified and point to the new MySQL. I was able to use 'sc' to
modify the service, and even specify --defaults-file to point to my new
'my.ini' at C:\MySQL50\my.ini
I'm still getting stuck...
|
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 not work under Win98.
I have read the info re dbghelp.dll and CRQE.dll under Win98 ad have
implemented the recommendations. This avoids the "Failed to load report"
error. http://support.businessobjects.com/library/kbase/articles/c2013420.asp
...
|
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 I know it's not
NTFS/share-level security at fault - it's readable to everyone which
is usually enough for scheduler or any other usually-not-network-user
to reach it.
I've checked my credentials in my remote session and it says it's
|
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 have the application deployed on WinXP
clients running in XP styles, all the controls become larger than the form
that
contain them. Even if I have the scrollbars set on auto, they won't show
up.
I've tried changing the XP machines back to...
|
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 list of services,
switched off anything that seemed to be a firewall, no luck.
So I compiled beta3 with mingw, installed, and now initdb keeps
telling me this:
| | |
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 using
mysql_free_result() function to free memory, but I'm still having
memory problems -- keep getting the memory exhausted error. I'm
developing this on Windows XP, but the live site is on Linux. Would
this problem be a glitch in my code, in...
|
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 real problems with the ASP side of
things.
Timeline of events is as follows:
1) Added IIS (via Add/Remove Windows Components) on WinXP Pro machine (6
|
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 port.
Also need to be able to set up the comms parameters Baud rate stop bits
parity etc.
Can anyone please advise or help me.
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
| | |
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| | |
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
