How TCP sends data synchronization? ? ? (Or is blocking block mode)

posts by CCDDzclxy edited 2013-11-01 11:02:04

RT

On the client, using something like the following code to send data:

 
PrintStream output = new PrintStream (skt.getOutputStream ()); 
output.write (bytes, 0, iLen); 
output.flush (); 

However executed, what phenomenon did not ... When the server off the network, the time to wait for about 2 minutes retransmission, in order to know each other off the network, or during the above code can be executed again ...

I think this: After I sent out a data, it waits until the data is sent successfully, or failed to send the order to continue to send, just use the Winsock API send the same? ? ?

Alternatively, after I finished sending data once, can have a status information to display, is now "the data being sent in" or "data has been successfully sent" or "data transmission failed"? ?
At least let me know about the situation, ah, do not ever let me wait until the end of the two minutes retransmission time, just let me know each other off the network ah ...

java novice, thanks for pointing.





<-! Main posts under Banner (D4) -><-! Posts under the main text (D5) ->
Reply:


In the client side is not a good judge whether sent successfully
To know whether the transmission is complete, the best way is the server in response to a state to you.
PrintStream output = new PrintStream (skt.getOutputStream ());
output.write (bytes, 0, iLen);
output.flush ();
/ / If we continue to execute the following code indicates that the data has been sent, as to whether the server receives is hard to say.
Reply:

cited a floor birdsaction reply:

want to know whether the transmission is complete, the best way is the server in response to a state to you.

There are advantages of such TCP what? ? So might as well get used UDP, get hold of yourself a simple retransmission mechanism .......
Reply:
TCP data transmission in theory, data reliable than UDP.
Clients are handled this way, you need a server response status.
Reply:
Heartbeat packet to determine the connection status
Reply:

reference to the third floor birdsaction reply:

TCP data transmission in theory, data reliable than UDP.

The so-called retransmission mechanism is reliable and what is not. Which already has a TCP receiver receives the data will return ACK, if the sender did not receive each other's time will be retransmitted ACK, this is the TCP comes inside. "The best way is to respond to a state server to you," this is not a waste of ACK? Not a waste of traffic? ? ?
Reply:

references, 4th Floor DrSmart reply:

heartbeat packet to determine the connection status

The other case off the network, heartbeat packets, not have to wait two minutes retransmission end time it ...
Reply:
You say that is the underlying TCP will ensure data integrity. Under normal circumstances without losing data.
If the network is unstable timeout exception would need to deal with their own.
Reply:

reference to the 7th floor birdsaction reply:

you say that is the underlying TCP will ensure data integrity. Under normal circumstances without losing data.
If the network is unstable timeout exception would need to deal with their own.

For example, I made a 30 consecutive times, respectively, the string "hello1", "hello2", "hello3" ... "hello30", but the other network is broken. Retransmission time of 2 minutes, then throw an exception, how do I know that I was in hello? When the other side off the net? Which string sent successful, which is not sent successfully? ? ?


Reply:
PrintStream output = new PrintStream (skt.getOutputStream ());
output.write ("hello" getBytes (), 0, iLen.);
output.flush ();
/ / If sending this hello, customers no exception occurs, can be understood as the string has been sent successfully, and less likely to send only the front two characters did not send back a few characters, if I did not send that packet loss , this situation is rare.

try {
PrintStream output = new PrintStream (skt.getOutputStream ());
output.write (bytes, 0, iLen);
output.flush ();
} Catch (Exception ex) {
/ / If an exception would need to deal with that string is not sent successfully.
}
Reply:
My client basically designed so that:
Thread receives data:

 
Runnable threadRecv = new Runnable () 
{
@ Override 
public void run () 
{
try 
{
byte [] byteRecv = new byte [RECV_BUF_LENGTH]; 

InputStream input = Fskt.getInputStream (); 

while (true) 
{
int iRecvLen = input.read (byteRecv, 0, RECV_BUF_LENGTH); 

if ((iRecvLen == 0) | | (-1 == iRecvLen)) 
{
. zcHandler.obtainMessage (THREAD_SKT_DEST_DISCONNECT) sendToTarget (); 

final String strBreak = 
"Socket closed by remote Maybe connection timeout ==>.. (" + Integer.toString (iRecvLen) + ")"; 
zcHandler.obtainMessage (THREAD_MSG, strBreak) sendToTarget ();. 

break; / / exit the loop 
} 

............ 
} / / While 
} 
catch (Exception ex) 
{
final String strErr = "Recv msg err:" + ex.getMessage () + "\ r \ n"; 
zcHandler.obtainMessage (THREAD_MSG, strErr) sendToTarget ();. 
. zcHandler.obtainMessage (THREAD_OVER) sendToTarget (); 
} 
} 
}; 

Code to send data:

 
Button btnTcpSend = (Button) findViewById (R.id.btnTcpSend); 
btnTcpSend.setOnClickListener (new Button.OnClickListener () 
{
@ Override 
public void onClick (View v) 
{
try 
{
FiIdx + +; 
PrintStream output = new PrintStream (Fskt.getOutputStream ()); 
output.write (FiIdx); 
output.flush (); 
} 
catch (Exception e) 
{
String strErr = e.getMessage (); 
zcMsg_Add ("Seng msg err:" + strErr); 
} 
} 
}); / / BtnTcpSend 

FiIdx class member variables are initialized to 0.

Test Procedure:
CLient machine and the machine in the same LAN Server, are XP. Android virtual machine running the client program to run on the Client machine.
1, Client connected to the Server.
2, connect the dots twice btnTcpSend, numbers 1, 2 sent out, server also received.
3, then immediately disable Server card, then immediately click btnTcpSend 3 times. (At this time of 12:52:15)
4, capture seen in figures 3,4,5 retransmission.
5, time 12:54:03, Android Client program displays information "Socket closed by remote. Maybe connection timeout. ==> (-1)". Client description at this time to know each other disconnected. (This information is displayed in the reception my thread inside information)


Here, I deliberately manually disconnect a network server, so I know the figures 3,4,5 not sent successfully. Well into practical application, how do I know which sends a success, which is not sent successfully? ?
ps: Client now also know that no other information is displayed
Reply:

reference to the 10th floor CCDDzclxy reply:

ps: Client now know no other information is displayed

Here's the "know" to "until" ...

Reply:
Under birdsaction and colleagues, regardless of the master is not a master, to come and pointing ah ~ ~ ~
Reply:
When you unplug the network cable from the socket perspective, this is difficult to judge, the network is just off the Socket interface can not know the details of what the physical layer.

Done before applications are generally catch the exception, or the server returns status, if you do not receive state would continue to allow the server to send the request.
Reply:

reference to the 13th floor birdsaction reply:

when you unplug the network cable from the socket perspective, this is difficult to judge, the network has just broken Socket Interface not know something more physical layer.

Done before applications are generally catch the exception, or the server returns status, if you do not receive state would continue to allow the server to send the request.

......