Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1264
  • Last Modified:

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

Can anyone help me out here?

Mike Paul
  • 3
1 Solution
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.
Firstly, I assume you are writing a chat room type client server app, and as such anything typed on the client is relayed to the server which then relays it to all clients "logged on".  If this is the case, are you appending newline characters when the Java server sends the lines back to the clients?  When you use the String reading methods in Java they typically read to the next newline character(s) and then strip them off, so try changing your write method in the server from:



output.writeString(string + "\n");

Also remember to flush your streams when you write, you dont want your TCP sockets to wait for more data before sending, you need each line sent as its typed to maintain continuuity and response time.


If this isnt the case, it is likely VB either isn't flushing the buffers when you write to your winsock control, or the newline characters are unrecognised by the mechanism you are using to read in one of the languages.

The first thing you can try is looking for a "flush" method for the winsock control, and if its there, calling it after a write operation.

I assume you are using a Reader interface for your Java server, and probably the getLine() method.  I'm not entirely sure whether this recognises all forms of newline termination (there were certainly issues with earlier implementations).  If your client applications display is capable of handling newlines etc by itself, you can dispense with that and use binary methods, like the basic read/write methods in the InputStream/OutputStream interfaces.

Alternatively, the same problem I mentioned above could be occuring on the read cycle of your VB client (I find this more likely as Java is designed for cross platform implementation.

If this is the case, you will need to either find a way to make the VB client recognise CR (character 13) line termination (which I believe Java uses), or append a LF (character 10) to each write performed by the server.

You could test this fairly easily, by changing your servers write mechanism from a typical:



output.writeString(text + (char)13 + (char)10);

Good luck
mikey_pAuthor Commented:
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

mikey_pAuthor Commented:
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:

            message = (String) input.readLine();
            display.append("\n" + message);
          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.
mikey_pAuthor Commented:
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.


Featured Post


Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now