VB.Net TCPclient app - Feedback from server

Question

4.00/5 (1 vote)

See more:

Hello,

I have created a vb.net tcp client application to stream a file to a server(which is listening on a port). Sometimes the server stops responding because it cannot handle the speed the data is being sent. This rate varies as it is being transported wirelessly. So, I would like to implement communication between the two. When the server is ready to accept more data, it will send a "ready" msg back to the client. Below is my code, does anybody know how to implement this....or point in the right direction?

Thanks,

-ren

VB

Dim clientsocket As New TcpClient(tbServer.Text, 1000) 'creates the connection to socket
Dim networkstream As NetworkStrea
networkstream = clientsocket.GetStream()
Using reader As New BinaryReader(File.Open(OpenFileDialog1.FileName, FileMode.Open))
Dim pos As Integer = 0
Dim length As Integer = reader.BaseStream.Length
Dim temp(txtbytes.Text) As Byte
While pos < length
networkstream.Write(temp, 0, temp.Length)
Threading.Thread.Sleep(200) ' control speed
pos += txtbytes.Text
End Using

Posted 25-Feb-11 9:10am

renasis_

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2011-02-25T16:48:00

I assume you're working at the speech recognition service or a service controlled by speech. Will you explain this? It this is a service controlled by speech, why not recognizing speed locally? Just asking. My sketch below should be applicable anyway, but you should elaborate further details depending on your application goals.

I would suggest you use TCP and a bit more high-level API: System.Net.Sockets.TcpListener on server side, System.Net.Sockets.TcpClient on client side.

On server side, you will need two separate threads: one listening for new client connection and updating a collection of client. Another one will read/write from/to networks stream on each remote (client) socket in sequence. Interlock collection update operations, but not socket operations (sockets are thread synchronization primitives themselves).

Each client should keep the session permanently. When client is disconnected by whatever reason (including power of on its computer), server's read/write thread should process exception and exclude the thread from the remote socket container.

What is "sending files"? There are no files in communication channel. There are only streams, so you need to send audio stream, probably enveloped into some data class to provide video size and other meta-data. At the level of the stream read/write operations between the server and clients, you need a simple application-level protocol to define the order of operation. For example, every client sends the audio and read response. The response should be polymorphous and include three message types: recognition result (including recognized test), busy status and ready status. Busy/ready status should be sent to all clients in sequence, recognition result — only to the client which requested it. If this is a service controlled by speech, you should provide recognition result along with command status. From this moment, you should clarify the application-level protocol based on your application requirements.

—SA