 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / May 2007TCP/IP comms problems between WinXP and DOS
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. >I am using VC++ 6.0 (with SP5 installed). When using WinXP this is with SP2 >installed. [quoted text clipped - 32 lines] >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. > >I am using VC++ 6.0 (with SP5 installed). When using WinXP this is with SP2 > >installed. [quoted text clipped - 47 lines] > 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 using VC++ 6.0 (with SP5 installed). When using WinXP this is with SP2 >> >installed. [quoted text clipped - 69 lines] >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 am using VC++ 6.0 (with SP5 installed). When using WinXP this is with SP2 > >> >installed. [quoted text clipped - 79 lines] > 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 am using VC++ 6.0 (with SP5 installed). When using WinXP this is with SP2 >> >> >installed. [quoted text clipped - 101 lines] >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 [quoted text clipped - 18 lines] > 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. On Apr 17, 9:28 am, Howard Smith <HowardSm...@discussions.microsoft.com> wrote: > I am using VC++ 6.0 (with SP5 installed). When using WinXP this is with SP2 > installed. [quoted text clipped - 11 lines] > 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 >I am using VC++ 6.0 (with SP5 installed). When using WinXP this is with SP2 > installed. [quoted text clipped - 39 lines] > 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. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.