Prev: How to implement a server socket compatible to telnet?
Next: Trouble Using Asis Tools
From: Dmitry A. Kazakov on 8 Aug 2008 14:51
On Fri, 08 Aug 2008 20:00:44 +0200, Dennis Hoppe wrote:

> Actually, some invocation of Ada.Streams.Read (Channel.all, Buffer,
> Index) should lead to
>
> Index < Buffer'Last
>
> if the end of the stream is reached.

You never reach the end of a TCP/IP stream unless the client closes the
socket, which is usually indicates an error.

The point is that you should never care about the stream end.

> I am now able to read line per line sent by the ftp server, but if
> I only once invoke my read method to often, the whole program hangs up
> due to the blocking behavior of Ada.Stream.Read.

No, it does because you incorrectly implement the protocol. Typically, you
send a request to the server and it answers with a chain of records. The
number and the content of the records is determined by the protocol. So you
can always know what to expect. Pseudo-code looks like

-- Processing a request
send request
loop
read one record
interpret the content of
exit when no records should follow
end loop
-- Ready to issue another request
...

You have mentioned FTP. There is a clear definition of how a FTP server
response ends:

"The client can identify the last line of the response as follows: it
begins with three ASCII digits and a space; previous lines do not. The
three digits form a code. Codes between 100 and 199 indicate marks; codes
between 200 and 399 indicate acceptance; codes between 400 and 599 indicate
rejection."
-- http://cr.yp.to/ftp/request.html

If you correctly implement the protocol your application will never block
unless the server is not busy. And you have to read out all response
otherwise the server will be block. So both parties know the states of each
other.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Dennis Hoppe on 8 Aug 2008 15:37
Dmitry A. Kazakov wrote:
> You never reach the end of a TCP/IP stream unless the client closes the
> socket, which is usually indicates an error.
>
> The point is that you should never care about the stream end.

Seems, that I am not as familiar with streams as I should ;)


> You have mentioned FTP. There is a clear definition of how a FTP server
> response ends:
>
> "The client can identify the last line of the response as follows: it
> begins with three ASCII digits and a space; previous lines do not. The
> three digits form a code. Codes between 100 and 199 indicate marks; codes
> between 200 and 399 indicate acceptance; codes between 400 and 599 indicate
> rejection."
> -- http://cr.yp.to/ftp/request.html
>
> If you correctly implement the protocol your application will never block
> unless the server is not busy. And you have to read out all response
> otherwise the server will be block. So both parties know the states of each
> other.

Yeah, I am used to the status codes, but I am struggeling with the
welcome message from ftp servers :-) FileZilla send three or four lines
of information, all with status code 220. By means of your weblink
(cr.yp.to - hehe), I saw the following:

150-This is the first line of a mark
123-This line does not end the mark; note the hyphen
150 This line ends the mark
226-This is the first line of the second response
226 This line does not end the response; note the leading space
226 This is the last line of the response, using code 226

This solves already the problem, because indeed the series of
consecutive commands is finished, if three digits were followed by a
blank. Each line of the welcome message begins with 220- and only the
last one with 220_ (blank).

Ok, I will never have a blocking read call in the future ;-)

Thank you very much, you made my day!

Best regards,
Dennis
From: Maciej Sobczak on 8 Aug 2008 17:25
On 8 Sie, 20:51, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de>
wrote:

> You never reach the end of a TCP/IP stream unless the client closes the
> socket, which is usually indicates an error.

This is not true. There are lots of protocols that use the end-of-
stream as an indicator of the end of request group. In such protocols
the client is free to issue new requests whenever he likes and the
server will dutifully *wait* for each of them.

Telnet is one such protocol. HTTP is another (client can ask for the
page and its dependent files like images via a single connection).
CORBA (and virtually every other RPC-like middleware) uses it for
handling many RPC requests from a single client. And so on - the list
is endless.

> The point is that you should never care about the stream end.

The point is that end of stream indicates that the client is not
interested in interaction anymore. This is a valid protocol state.

This is different from the client's perspective, but I can imagine
protocols where the server can respond with potentially endless
answer, not necessarily continuous in time (online stock price
updates?), and finish after a timeout or some other even that is
outside of the client's control. Again, end of stream is a valid
protocol state.

> If you correctly implement the protocol your application will never block

Your application can also block if the other party blocks in the
middle of responding. You cannot fully control it.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com
From: anon on 8 Aug 2008 23:04
Check the source files for the "Ada Terminal Emulator - version 2.3"

http://members.optusnet.com.au/~rosshigson/terminal.htm#_Source_Distribution_1

Binaries and Source can be found there. Since, both TELNET and FTP protocols
are related you should be able to find out how they goyt around the blocking
concept. Or they may even created a query routine that you might be able to
adopt for your program.

Note: In the emulator the package uses it own Sockets packages which is just
a renamed version of the GNAT.Sockets packages.

In <g7hher$mtt$1(a)aioe.org>, Dennis Hoppe <dennis.hoppe(a)hoppinet.de> writes:
>Hi,
>
>I've written a minimal example to access an ftp server (like FileZilla).
>First, let's have a look at the code snippet:
>
>-- START
>with Ada.Text_IO;
>with Ada.Streams;
>with GNAT.Sockets; use GNAT.Sockets;
>use type Ada.Streams.Stream_Element_Count;
>
>procedure Test is
> Client: Socket_Type;
> Address: Sock_Addr_Type;
> Channel: Stream_Access;
> Data : Ada.Streams.Stream_Element_Array (1 .. 1);
> Offset : Ada.Streams.Stream_Element_Count;
>
>begin
> Initialize;
> Create_Socket(Client);
> Address.Addr := Inet_Addr("127.0.0.1");
> Address.Port := 21;
> Connect_Socket (Client,Address);
> Channel := Stream(Client);
>
> loop -- reads in the welcome message
> Ada.Streams.Read (Channel.all, Data(1..1), Offset);
> exit when Offset = 0;
> -- alternative: exit when Offset /= Data'Last
> for I in 1 .. Offset loop
> Ada.Text_IO.Put (Character'Val (Data (I)));
> end loop;
> end loop;
>end Test;
>-- END
>
>The problem is, that Ada.Streams.Read is blocking, if the end of the
>stream is reached. I found many examples, that outline, that the
>variable Offset will be 0, if no further elements are on the stream.
>But this seems not to be the case, unfortunately.
>
>For a ftp server/client situation, each command is terminate by <CRLF>,
>so I enhanced the exit condition to:
>
>loop
> Ada.Streams.Read (Channel.all, Data(1..2), Offset);
> exit when (Character'Val (Data(1)) = ASCII.CR and Character'Val
>(Data(2)) = ASCII.LF);
> -- code omitted
>end loop;
>
>Of course, the Stream_Element_Array is enhanced to (1..2).
>
>This approach works very well, but some ftp commands send a messages
>over several lines. I do not know in advance, how many lines I should
>read in. Subsequently, Ada.Streams.Read has to be called in a loop,
>which will eventually block, again.
>
>How can I query the stream, if new elements are ready to read?
>
>Many thanks in advance,
> Dennis

From: Dmitry A. Kazakov on 9 Aug 2008 03:30
On Fri, 8 Aug 2008 14:25:33 -0700 (PDT), Maciej Sobczak wrote:

> On 8 Sie, 20:51, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de>
> wrote:
>
>> You never reach the end of a TCP/IP stream unless the client closes the
>> socket, which is usually indicates an error.
>
> This is not true. There are lots of protocols that use the end-of-
> stream as an indicator of the end of request group.

I meant Ada stream associated with the socket. You cannot end it otherwise
than by closing the socket, if at all. I didn't look into GNAT sockets, but
it is well thinkable that it implementation never ever ends the stream and
instead of that raises Socket_Error upon an I/O on a closed socket.

> In such protocols
> the client is free to issue new requests whenever he likes and the
> server will dutifully *wait* for each of them.

No, that is full-duplex communication, which technically is not
client-server. But in this case too, end of stream is never used to bound a
request or response. It would be wasting resources. Worse than that, it
would make the protocol unusable for the cases where the connection cannot
be dropped, like serial communications, CAN bus, etc.

>> The point is that you should never care about the stream end.
>
> The point is that end of stream indicates that the client is not
> interested in interaction anymore. This is a valid protocol state.

(OP designed a client)

> This is different from the client's perspective, but I can imagine
> protocols where the server can respond with potentially endless
> answer, not necessarily continuous in time (online stock price
> updates?), and finish after a timeout or some other even that is
> outside of the client's control. Again, end of stream is a valid
> protocol state.

Surely, the network protocol for data exchange I designed for a middleware
has exactly this design. Many other protocols used in automotive industry
are of full-duplex asynchronous nature. But end of stream is never used
there, otherwise than to indicate broken connection.

>> If you correctly implement the protocol your application will never block
>
> Your application can also block if the other party blocks in the
> middle of responding. You cannot fully control it.

Yes, I wrote "unless server is busy." This is not blocking. Compare it with
the way Ada defines a potentially blocking operation. A non-blocking
operation is not meant instant, it is time-bounded. Delays caused by
network latencies, server load etc semantically are not lookups.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: How to implement a server socket compatible to telnet?
Next: Trouble Using Asis Tools