Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.unix.programmer > #846 > unrolled thread

socket programming. read from server.

Back to article view | Back to comp.unix.programmer

Contents

  socket programming. read from server. Steve Richter <stephenrichter@gmail.com> - 2011-06-22 06:37 -0700
    Re: socket programming. read from server. Steve Richter <stephenrichter@gmail.com> - 2011-06-22 08:12 -0700
    Re: socket programming. read from server. Richard Kettlewell <rjk@greenend.org.uk> - 2011-06-22 16:31 +0100
    Re: socket programming. read from server. Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-06-22 16:42 +0100
    Re: socket programming. read from server. David Schwartz <davids@webmaster.com> - 2011-06-22 09:00 -0700
      Re: socket programming. read from server. Steve Richter <stephenrichter@gmail.com> - 2011-06-22 09:05 -0700
    Re: socket programming. read from server. "Heinrich Wolf" <invalid@invalid.invalid> - 2011-06-22 22:50 +0200
    Re: socket programming. read from server. Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-06-22 22:22 -0400
      Re: socket programming. read from server. Michael Press <rubrum@pacbell.net> - 2011-06-24 14:08 -0700

#846 — socket programming. read from server.

when a client reads from a socket, how does it know the server has
completed sending and is itself currently blocking on a read from the
client?

I am writing a small ftp client in C for the IBM AS400 using the UNIX
APIs. When the client code connects to the FTP server it reads back
the initial welcome messages. My code reads from the server, gets
some /r terminated messages. Reads again and gets more /r terminated
welcome messages. Then reads a 3rd time and blocks because there is
nothing more to read.  What in the socket protocol tells me the 3rd
read is going to block?


thanks,

[toc] | [next] | [standalone]

#847

On Jun 22, 9:37 am, Steve Richter <stephenrich...@gmail.com> wrote:
> when a client reads from a socket, how does it know the server has
> completed sending and is itself currently blocking on a read from the
> client?
>

I see I use fcntl to put the socket in non blocking mode.  But maybe
the server is slow and still has more data to send when the client's
read returns "will block". Does this mean the program on the other end
of the connection has to place something in the data it sends to
indicate it is done sending?

[toc] | [prev] | [next] | [standalone]

#848

Steve Richter <stephenrichter@gmail.com> writes:
> when a client reads from a socket, how does it know the server has
> completed sending and is itself currently blocking on a read from the
> client?
>
> I am writing a small ftp client in C for the IBM AS400 using the UNIX
> APIs. When the client code connects to the FTP server it reads back
> the initial welcome messages. My code reads from the server, gets
> some /r terminated messages. Reads again and gets more /r terminated
> welcome messages. Then reads a 3rd time and blocks because there is
> nothing more to read.  What in the socket protocol tells me the 3rd
> read is going to block?

You need to read the description of multi-line replies in the FTP RFC.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#849

Steve Richter <stephenrichter@gmail.com> writes:

[...]

> I am writing a small ftp client in C for the IBM AS400 using the UNIX
> APIs. When the client code connects to the FTP server it reads back
> the initial welcome messages. My code reads from the server, gets
> some /r terminated messages. Reads again and gets more /r terminated
> welcome messages. Then reads a 3rd time and blocks because there is
> nothing more to read.  What in the socket protocol tells me the 3rd
> read is going to block?

Nothing. The FTP protocol definition (RFC959), however, would tell you
that a server reply is either a single line reply composed of a
3-digit reply code, followed by an ASCII space character (0x20),
possibly followed by some informative text and terminated by a telnet
end-of-line sequence (ASCII CR, ASCII LF), or that it is a multiline
reply. In the latter case the first line will have a hypen (-) instead
of a space after the reply code and the last line will start with the
same reply code as the first, this time followed by a space.

More details:

	http://www.faqs.org/rfcs/rfc959.html

[toc] | [prev] | [next] | [standalone]

#851

On Jun 22, 6:37 am, Steve Richter <stephenrich...@gmail.com> wrote:

> when a client reads from a socket, how does it know the server has
> completed sending and is itself currently blocking on a read from the
> client?

That depends on the protocol. Read the protocol specification to find
out.

> I am writing a small ftp client in C for the IBM AS400 using the UNIX
> APIs. When the client code connects to the FTP server it reads back
> the initial welcome messages. My code reads from the server, gets
> some /r terminated messages. Reads again and gets more /r terminated
> welcome messages. Then reads a 3rd time and blocks because there is
> nothing more to read.  What in the socket protocol tells me the 3rd
> read is going to block?

Nothing. That's not the socket protocol's job. Since this is the FTP
protocol, the FTP protocol specification should tell you. And the FTP
specification indeed says that the last line will have a space after
the reply code.

DS

[toc] | [prev] | [next] | [standalone]

#852

On Jun 22, 12:00 pm, David Schwartz <dav...@webmaster.com> wrote:
> On Jun 22, 6:37 am, Steve Richter <stephenrich...@gmail.com> wrote:
>
> > when a client reads from a socket, how does it know the server has
> > completed sending and is itself currently blocking on a read from the
> > client?
>
> That depends on the protocol. Read the protocol specification to find
> out.
>
> > I am writing a small ftp client in C for the IBM AS400 using the UNIX
> > APIs. When the client code connects to the FTP server it reads back
> > the initial welcome messages. My code reads from the server, gets
> > some /r terminated messages. Reads again and gets more /r terminated
> > welcome messages. Then reads a 3rd time and blocks because there is
> > nothing more to read.  What in the socket protocol tells me the 3rd
> > read is going to block?
>
> Nothing. That's not the socket protocol's job. Since this is the FTP
> protocol, the FTP protocol specification should tell you. And the FTP
> specification indeed says that the last line will have a space after
> the reply code.
>
> DS

that answers my question. thanks for both replies.

[toc] | [prev] | [next] | [standalone]

#853

"Steve Richter" <stephenrichter@gmail.com> schrieb im Newsbeitrag 
news:88dc219d-5c3e-4d01-8b32-5280eaffcd04@l6g2000vbn.googlegroups.com...
> when a client reads from a socket, how does it know the server has
> completed sending and is itself currently blocking on a read from the
> client?
>
> I am writing a small ftp client in C for the IBM AS400 using the UNIX
> APIs. When the client code connects to the FTP server it reads back
> the initial welcome messages. My code reads from the server, gets
> some /r terminated messages. Reads again and gets more /r terminated
> welcome messages. Then reads a 3rd time and blocks because there is
> nothing more to read.  What in the socket protocol tells me the 3rd
> read is going to block?
>
>
> thanks,

Hello,

recv() might return 0 bytes.
You might also use signal(SIGALRM, ) and alarm() to catch a timeout
or you might use ioctlsocket( , FIONBIO, )

This applies to all socket communication, not only ftp.

kind regards
Heiner

[toc] | [prev] | [next] | [standalone]

#854

On 6/22/2011 9:37 AM, Steve Richter wrote:
> when a client reads from a socket, how does it know the server has
> completed sending and is itself currently blocking on a read from the
> client?

     By inferring it from the mutually agreed-upon protocol.  Ever
see disciplined use of a two-way radio?  On a TV cop show, perhaps?
Notice how the speaker always says "Over" to advertise that he's
finished speaking and will now listen?  And "Out" to indicate that
the conversation is finished?  (And the completely nonsensical "Over
and out" to indicate that the dialog was written by someone who's
never used a radio?)  Those messages are part of a protocol to manage
the communication, something decided before communication begins.
Your client and server must similarly decide on channel-management
protocols (simple or complex) beforehand.

> I am writing a small ftp client in C for the IBM AS400 using the UNIX
> APIs. When the client code connects to the FTP server it reads back
> the initial welcome messages. My code reads from the server, gets
> some /r terminated messages. Reads again and gets more /r terminated
> welcome messages. Then reads a 3rd time and blocks because there is
> nothing more to read.  What in the socket protocol tells me the 3rd
> read is going to block?

     If it's an FTP client, it must follow the FTP protocols as
described in the RFC's (GIYF).  If it doesn't follow those protocols
when the FTP servers expect it to, you can anticipate difficulties
of exactly the same kind you'd get if the radioman said "Repeat"
instead of "Out" and "Zooglobble" instead of "Over."

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#865

In article <itu835$ads$1@dont-email.me>,
 Eric Sosman <esosman@ieee-dot-org.invalid> wrote:

>      If it's an FTP client, it must follow the FTP protocols as
> described in the RFC's (GIYF).  If it doesn't follow those protocols
> when the FTP servers expect it to, you can anticipate difficulties
> of exactly the same kind you'd get if the radioman said "Repeat"
> instead of "Out" and "Zooglobble" instead of "Over."

Forward artillery spotters never said 
"repeat" when they meant "say again." :)

-- 
Michael Press

[toc] | [prev] | [standalone]

Back to top | Article view | comp.unix.programmer

csiph-web