Link to home
Start Free TrialLog in
Avatar of mikey_p
mikey_p

asked on

winsock communicating with java

I have a simple tcp client in vb6 using the winsock control and a tcp
server in java using sockets. I wish to send text information between
them. Both apps sit on the same machine.

The vb client and java server connect fine, and I can send text from
the java server and the vb client picks it up straight away...and can
continue this as long as the connection is open

My PROBLEM is when I try sending text from the VB client, the java
server does not receive it... until I close the connection from the VB
side - which I don't want to do. I am using the SendData method. I can
get 2 vb apps to work fine and 2 java apps to work fine but not vb and
java.

Can anyone help me out here?

Thanks
Mike Paul
Avatar of urbiman
urbiman

For me it seems that vb buffers the data an send them when the application is closed.
To solve this problem the vb Buffer has to be flushed.
I don't know exactly what Method that is.

To see what is really happening I would suggest you to use ethereal(www.etheral.com).so you can see what packets are actually sent and which programs fault it is.
ASKER CERTIFIED SOLUTION
Avatar of UncleJimbo
UncleJimbo

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of mikey_p

ASKER

to urbiman : I don't think it is a problem with the buffer not being flushed as if I use a vb server with the vb client all data is sent immediately each time I use the SendData method of the winsock control. Also in VB6 there does not appear to be a method for flushing the buffer.

Will look into ethereal, looks a bit heavy for me at the moment.

Thanks for comment

Avatar of mikey_p

ASKER

UncleJimbo and others:To clarify scenario - at the moment I'm just trying to do a proof of concept ie I want a vb6 app to send a java app, sitting on the same machine, a text string and for the java app to be able to do the same in reverse. Web services at the moment are not in the equation as there will be no webserver on the machine. Sockets and TCP seems potentially a way forward. I am using simple chat room clients and servers to this end.

The code for the VB6 to send data is as follows:

Private Sub cmdSend_Click()
   
    'send data to server
    'tcpClient = Winsock control
   
    Call tcpClient.SendData("VBClient>>> " & txtSend.Text)
   
    txtOutput.Text = txtOutput.Text & _
        "VBClient>>> " & txtSend.Text & vbCrLf
        txtOutput.SelStart = Len(txtOutput.Text)
        txtSend.Text = ""
       
End Sub

The java code to receive data is as follows:

do
        {
          try
          {
            message = (String) input.readLine();
            display.append("\n" + message);
            display.setCaretPosition(display.getText().length());
          }
          catch(IOException e)
          {
            display.append("\nError reading message");
          }
         
        }while (!message.equals("CLIENT>>>Terminate"));

with input being a BufferedReader.

For some reason the java socket does not seem to receive the data from the VB client although the client thinks it has sent it. The java server only receives the data - all data from any previous sends whilst connection has been open, when the winsock connection is closed. With a VB server the data is received instantly on cmdSend_click.

As mentioned in previous comment, I can find no flush method for the Winsock control.

The Vb client receives data fine from the java server. I hope this clarifies the problem a little better.
Avatar of mikey_p

ASKER

UncleJimbo: after I replied initially to you read your answer more carefully. It would appear to me that the BufferedReader.Readln method I am using was not seeing a new line identifier any where and thus not getting the data.

I've actually used your suggestion of using (char)13 and (char)10 but from the Vb SendData side, appending Chr(13) and Chr(10) to the sent text and this does the trick. Thanks again and thanks to urbiman for responding.