Sockets and EOF Question

[journy101]

Trying to get my head around the idea of eof in sockets. Its the concept I want help with not the code.

If I conect a socket to my localhost mail server. Now say I send the command help. The server obviously responds with mutiple lines of data. I need to get all this data into a buffer before I can send more commands.

So I read examples and they all seem to use a loop and test for the EOF, and if EOF is reached then the loop breaks and they send more commands. So all data can be recieved.

Now I have tryed this with a function called feof which tests the socket handle for EOF. But i have noticed there is never an EOF.

Is there not suposed to be a EOF at the end of each line of server responce?

Here is a hex dump from my responces i got:

32 32 30 20 41 72 47 6f 53 6f 66 74 20 4d 61 69 6c 20 53 65 72 76 65 72 20 46 72 65 65 77 61 72 65 2c 20 56 65 72 73 69 6f 6e 20 31 2e 38 20 28 31 2e 38 2e 33 2e 34 29 0d 0a 32 35 30 20 57 65 6c 63 6f 6d 65 20 20 5b 31 32 37 2e 30 2e 30 2e 31 5d 2c 20 70 6c 65 61 73 65 64 20 74 6f 20 6d 65 65 74 20 79 6f 75 0d 0a

And this is what it looked like:

220 ArGoSoft Mail Server Freeware, Version 1.8 (1.8.3.4)
250 Welcome [127.0.0.1], pleased to meet you

See how each line ends in CR LF 0d 0a

But this is not a EOF corect?

Can someone explain how looping for EOF would let me grab all lines?

The above responce is not the problem, just to show what my lines end in CR LF, but if I did for example HELP then just fgets does not grab all lines only one,

[slarty]

In stream sockets (which I assume you refer to, because they are the only kind which have a notion of EOF), you can have an EOF condition. This is not marked by a sequence of data, but by reading zero bytes from the socket.

Normally, you would read a chunk of stuff from the socket with read() or recv() (Windows: recv() only).

Read the man page: This function returns the number of bytes read. However, it returns -1 on an error, and returns zero *only* if the socket has been closed at the other end (i.e. an EOF).

Note that this is consistent with what happens if you do a read() on a regular file which is at the end (although the low-level read() call is rarely used directly on regular files, normally one would use the stdio functions, fread() instead)

If you try to read again from a socket which the other end has been closed on, you will get zero again (unless you've closed it).

Be aware that in any network app, error handling is important, remember that you may get an error from read() indicating that the connection has been closed in an abnormal way (i.e. it got broke).

If you're waiting for a message from the socket, by using select() or poll() in Unix, or WSAASyncSelect in Windows, then the socket will be flagged as being ready to read even though there may be no data. In this case, you should recognise this otherwise you might end up busy-waiting unintentionally.

feof() which you mentioned, is for stdio streams, which can in principle refer to sockets, but the socket() function does not return one and there is no corresponding fsocket(). I'm not sure exactly how you'd make one, or how portable the resulting program would be.

[(V)/\><]

use a loop and test for the EOF, and if EOF is reached then the loop breaks and they send more commands.

read all the data in one go and then go through it afterwards to find the crlf.

as that is end of line signature. if thats what you are trying to find.

[slarty]

Ok, I think I see what you want.

Ignore my first reply, it was correct but not what you're looking for.

You want to know when the response from the server has finished so that you can send another command (as a client)?

You don't want to read until the EOF, trust me, otherwise you'll be waiting until the server disconnects you for being idle too long.

You just want to read lines until the response is finished? What does the SMTP protocol say about knowing when the response is finished? Is a "250" response always sent after any others to indicate that it's ready for another command?

If so, you can just read lines in, and wait for one with a "250". Go and read the SMTP doc and see what it says.

TCP is stream-oriented, not message oriented, so different protocols use different methods to distinguish where a message ends (if indeed they use messages at all)

[journy101]

Yes, I want to read lines until the response is finished.

Looking over your responces carefully. This is makeing much more sence now.

I did notice when I looped waiting for EOF the conection went idle just sat there, I watched the conection come into my mail server, Then I saw Connection eventualy reset by peer after sitting there for a while. This explains why.

You don't want to read until the EOF, trust me, otherwise you'll be waiting until the server disconnects you for being idle too long.

Ahh, thats why!!!

It makes sence to read lines from the socket and test for 250, the go ahead. I have read parts of RFC 821 and RFC 1425. Familiar with some of the responces, but can look up as I need them....

If I ehlo instead of helo I get a set of mutliple 250 headers:

250-Welcome [63.146.109.240], pleased to meet you
250-AUTH=LOGIN
250-AUTH LOGIN
250-SIZE 5242880
250 HELP

Ahh, a patern, the - sign indicates there is more data? I see now I could test for "^250 " with regex, then if so I can send more commands. Perfect I can do this.

Thank you both, I am still thinking about the sugestion to test for CR LF. But unsure that would work, as every line has it, even the finishing line. Whereas the finsihing line seems to always have 250 with a space.

Thanks everybody.