Re: socket reading...

If the TCP server is keeping the connection open (that is, not doing a C close(2) on the socket) and if the server does not set the PSH (push) bit on the TCP segments containing the newlines, the last portion of data may not make it to your application for some time.

If you control the application server, you can likely control the first aspect: closing the socket. You may or may not be able to cause the PSH bit to be set.

As wog noted, sysread returns 0 (the number of bytes read) on EOF, but it is only EOF iff the socket is closed by the server.

--traveler

Comment on Re: socket reading... Select or Download Code

Replies are listed 'Best First'.
Re: Re: socket reading... by jdv79 (Sexton) on Jul 28, 2001 at 03:50 UTC
The problem with that is that the TCP server is a relaitvely dumb host and does not have the ability to close the socket. My client has to do that. From what I am hearing and what I have been trying since my initial post is that the best way to exit the recieve stream read would be to match on the prompt even though I cant see it from the client. This presents a slight issue.	[reply]
Re: Re: Re: socket reading... by traveler (Parson) on Jul 28, 2001 at 19:37 UTC
You could try to send some sort of a NOP (e.g. just an empty request or newline equivalent). That might force the server to send out some more data (e.g. prompts) causing your client host to flush the buffer to the application. Enough NOP packets might get you a prompt to your app. You'd have to skip empty prompts on the next read if they are not all delivered to your application.	[reply]