 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / January 2008Calling an MFC-Socket vom Java
Hallo, I have an C++/MFC-Program that creats a socket server via a class derived from CSocket. In its ::OnReceive()-Method it does its job. In a Java-Class, this socket is opened (new Socket()) and its Input- and OutputStream used for communication. That works so far. However: sometimes(!) the communication is broken. The Request from the java-Part is not received in the OnReceive()- Method in the MFC-Server. So, everything hangs, the Java-part is waiting infinitely for an answer that is not computet, because the Server did not receive the request. debug-output has shown, that the previous OnReceive()-method in the C+ +/MFC-part did run to an end - seemingly without any error. But after that, it does not receive anymore. The writing of data into the OutputStream also did not result in an Exception. I thought, one process overtook the other, so i put in a sleep in the java-part after receiving any answer - but it did not work. Curiosly enough - the problem does not occur on every PC, but there are PCs where the error occurs more often that on others. Also we had a nearly a whole day where the error did not occur at all! It also does not occur alway at the same call. It is seamingly random - but I dont think so. There must be a reason. We are complete at a loss. Is there any important status, that we could read before sending the request in java? Is there any way to check if the MFC-Socket is still open and listening? Is there a way to restart the socket? Thanx for any help - we really could do with a hint Goetz > I have an C++/MFC-Program that creats a socket server via a class > derived from CSocket. In its ::OnReceive()-Method it does its job. [quoted text clipped - 7 lines] > waiting infinitely for an answer that is not computet, because the > Server did not receive the request. If the communication were *broken* you would get an indication indication that fact when either reading or writing. Possibly your protocol does not account for the fact that TCP does not preserve message boundaries. Message sometimes arrive in parts, and two messages can arrive together. Use a tool like Wireshark to see what's actually happening on the network. Probably you should post some example code. /gordon -- > > I have an C++/MFC-Program that creats a socket server via a class > > derived from CSocket. In its ::OnReceive()-Method it does its job. [quoted text clipped - 23 lines] > > -- Hi, thanx for the ideas. Here's the code: Writing the Steam in Java ====== public void sendData(String data) { writer.println(startTransmit); writer.println(data); writer.println(endTransmit); writer.flush(); } ====== (startTransmit and endTransmit are begin and end signs to synchronize the communication.) Reading in Java ====== public String receiveData() throws IOException { String retStr = null; recvBuffer = new StringBuffer(200); do { retStr = reader.readLine(); if( retStr == null ) return(null); // Connection lost ? }while(checkReceiveContent(retStr)); return(recvBuffer.toString()); } ====== (checkReceiveContent() checks, if the endTransmit-Code is received and returns true, false otherwise) So, the connection is flushed and synchonized. The MFC-Part uses CSocket::Receive() and CSocket::Send() to communicate. Up to now, the return code from CSocket::Send is ignored. I the lunch break I have heard rumours about a possible java error in the actual JRE. We are using ======= java version "1.6.0_02" Java(TM) SE Runtime Environment (build 1.6.0_02-b06) Java HotSpot(TM) Client VM (build 1.6.0_02-b06, mixed mode) ======= Thanx, Goetz > Hi, thanx for the ideas. > > Here's the code: How long is a typical message? Does the other side loop in a similar manner when reading the incoming messages? > I the lunch break I have heard rumours about a possible java error in > the actual JRE. Once again: get Wireshark and look at the actual traffic. All else is speculation. /gordon -- > > Hi, thanx for the ideas. > [quoted text clipped - 12 lines] > > -- Hi, i got and installed wireshark. Can anyone tell me a good filter? The Communication is between "localhost" on port 4441. Thanx, Goetz > i got and installed wireshark. Can anyone tell me a good filter? The > Communication is between "localhost" on port 4441. Assuming you mean "capture filter", something like "port 4441" or "proto tcp and port 4441" should work. /gordon -- > Assuming you mean "capture filter", something like > "port 4441" or "proto tcp and port 4441" should work. > > /gordon > > -- Sounds good. But how can I capture localhost? The Capture-Dialog only displays the Interfaces and a local communication does not run through my network device, right? How can I capture 'localhost'? Sorry, but you see, I am to total wireshark-newbie. Goetz > Sounds good. But how can I capture localhost? The Capture-Dialog only > displays the Interfaces and a local communication does not run through > my network device, right? > > How can I capture 'localhost'? There is a capture menu where you can specify the interface to capture from. On some platforms, you might be able to capture from the localhost device. Or, instead of connecting via "localhost", have your client connect to the hosts "real" interface instead by specifying that address instead when you connect (i.e. 192.168.128.3 instead of 127.0.0.1). That may be sufficient to make the traffic available to Wireshark, even though no traffic will actually get sent on the network in either case. If that doesn't do it, then you need to run one of the processes on a different host, then run Wireshark on either the client or the server host. /gordon -- >> Assuming you mean "capture filter", something like >> "port 4441" or "proto tcp and port 4441" should work. [quoted text clipped - 12 lines] > > Goetz You can't on Windows. You will need to modify your code so it uses the IP address of the interface, rather than 127.0.0.1, localhost or whatever you use.  SignatureNigel Wade, System Administrator, Space Plasma Physics Group, University of Leicester, Leicester, LE1 7RH, UK E-mail : nmw@ion.le.ac.uk Phone : +44 (0)116 2523548, Fax : +44 (0)116 2523555 gobo schrieb: > Hallo, > [quoted text clipped - 32 lines] > Thanx for any help - we really could do with a hint > Goetz amke shure you are calling flush() on the outgoing stream. That might be the problem. For further guessing it might be better if you posted some of your code. Christian 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.