Current archive: 2002.04.01;
Work with sockets Find similar branches← →
Valdemar (2002-01-17 14:37) 
I work with a socket in synchronous mode. How do I determine that there is unread data in the incoming stream. If you can try.
Thanks in advance.
Digitman (2002-01-17 14:41) 
in synchronous mode, nothing needs to be defined. In this mode, the OnRead event occurs exactly when there is data available for reading in the input stream.
Valdemar (2002-01-17 16:16) 
Then why doesn't a piece of code work?
procedure TForm1.ServerSocket1ClientRead (Sender: TObject;
socket. ReceiveBuf (tr, sizeof (tr));
Digitman (2002-01-17 17:25) 
1. Why - Application.ProcessMessages?
2. What does it mean - "not working"?
Valdemar (2002-01-17 18:03) 
Application.ProcessMessages so that the application does not freeze when it waits for data
And does not work as it does not get here
Digitman (2002-01-17 18:15) 
And why should the application "hang" something? Is it some kind of long cycle you have in the OnClientRead handler? You don't have any cycles before reading the buffer, as far as it is obvious from your fragment.
"Not getting" means either the client does not transmit anything, or the server is inactive, or it is ThreadBlocking, or ... you never know what other reasons!
Are you sure that the “client” has successfully connected to the server? On the basis of what sure? Event OmClientCoinnect to occur? If - occurred, then the OnClientRead event should also occur. And if it is not there, then either the connection is already broken, or the “client” does not send anything or sends it incorrectly, or ... again, you never know what!
Valdemar (2002-01-17 19:03) 
The fact is that the server is onThreadBlocking
Valdemar (2002-01-17 22:20) 
I am sure that the client connects correctly, because when onAccept occurs, I read the data normally, but I cannot read the next portion of the data.
Digitman (2002-01-18 08:54) 
Threadblocking, you say?
Then I can assume with sufficient confidence share that you did not think of overriding the TServerClientThread class. And I didn’t even look at the implementation of his ClientExecute method. Right? Then look here, I will do the work for you on analyzing what is happening in the transport stream of the client connection on the ThreadBlocking server:
procedure TServerClientThread.ClientExecute; var FDSet: TFDSet; TimeVal: TTimeVal; begin // there is no signal about the completion of the traffic flow And the transport is active while not terminated and clientsocket.connected do begin FD_ZERO (FDSet); FD_SET (ClientSocket.SocketHandle, FDSet); TimeVal.tv_sec: = 0; TimeVal.tv_usec: = 500; // wait for half a second, checking the status of the WSAEvent event object associated with the socket if (select (0, @FDSet, nil, nil, @TimeVal)> 0) and not Terminated then // if the WSAEvent event object is in the Signaled state (more precisely, it signals the FD_READ event) And the thread is not notified yet from the outside about the need to end, then: if ClientSocket.ReceiveBuf (FDSet, -1) = 0 then // if the socket's read buffer is empty Break // exit from cycle, completion of transport, client connection will be broken - no more data from client else Synchronize (DoRead); // initiate the OnClientRead event in the main stream where the buffer can be read (in whole or in part) if (select (0, nil, @FDSet, nil, @TimeVal)> 0) and not Terminated then Synchronize (DoWrite); // initiate the OnClientWrite event once to inform about the readiness of the socket to transfer data to the client end; end;
Digitman (2002-01-18 09:00) 
Thus, in the OnAccept () event, you scooped out the socket's read buffer, the buffer is empty (the client did not transmit anymore), and the transport goes into Disconnected state (the client is simply turned off by the server), and the transport stream either ends or is returned by the dispatcher to the free pool ( with KeepInCache = True)
Pages: 1 whole branch
Current archive: 2002.04.01;
Memory: 0.57 MB
Time: 0.041 c