I thought everyone who watches the LiS list might be interested in this.
-- Dave
-------- Original Message --------
Subject: RE: STREAMS driver for TCP.
Date: Mon, 19 Mar 2001 12:07:12 -0000
From: "Martin Boll" <[EMAIL PROTECTED]>
To: "'Ole Husgaard'" <[EMAIL PROTECTED]>,"John Hodgkinson"
<[EMAIL PROTECTED]>,"Dave Grothe" <[EMAIL PROTECTED]>,"Mohd Salim
Ansari" <[EMAIL PROTECTED]>
I thought it might be helpful if I made a brief status report on my
progress
with Ole's Linux Streams driver for TCP. I'm testing it in conjunction
with
some software of ours which is effectively a Streams module implemention
of
the RFC1006 protocol. Our software has previously been used
successfully on
a number of other Streams platforms (DG/UX, Solaris, AIX, UnixWare etc
etc.)
During this testing I have found the following problems:
1) In 'ws_conn_res()', when accepting on a different endpoint, the code
checks that the 'sport' fields of the sockets associated with the two
endpoints are the same. This test seems to me to be unnecessary and
incorrect; the port for the accepting endpoint will most likely be
assigned
randomly if it was not specified (specified as zero) in the T_BIND_REQ
for
the new endpoint. As our software, which specifies this port as zero,
works
on all the other platforms mentioned, I am inclined to believe that the
problem lies within 'ws_conn_res()' rather than within our software, so
I
have changed 'ws_conn_res()' so it no longer does this test.
2) I was keen to avoid the necessity of patching the underlying Linux
TCP
code, so for the time being I have changed 'ws_discon_req()' to work in
a
similar way to 'ws_ordrel_req()' and call functions within the existing
unmodified Linux TCP driver.
3) Our software opens the Streams TCP device during its initialisation,
then
goes through the sequence 'bind', 'connect', 'disconnect' and 'unbind'
for
each successive connection over the stream. I have had a lot of
difficulty
because after completion of the first cycle, on the 'bind' of the second
cycle the states of the underlying socket and TCP device are incorrect.
I
am currently trying to tackle this problem by moving the 'sock_create()'
and
'attach_sock()' calls from 'tcp_open()' to 'ws_bind_req()', and
similarly
moving the 'detach_sock()' call from 'tcp_close()' to 'ws_unbind_req()',
so
we effectively have a fresh socket for each connection. I am still
working
on this.
Salim, have you done anything with this driver yet? If you have, I'd be
interested to hear how you've been getting on. Have you encountered any
of
the above problems, or any others?
Best regards,
Martin
------
Martin Boll
Protek Boldon James, Crewe, UK
Tel: +44(0)1270 507859
Fax: +44(0)1270 507801
mailto:[EMAIL PROTECTED]
http://www.bj.co.uk
> -----Original Message-----
> From: Ole Husgaard [mailto:[EMAIL PROTECTED]]
> Sent: 01 March 2001 14:02
> To: Martin Boll; John Hodgkinson; Dave Grothe; Mohd Salim Ansari
> Subject: Re: STREAMS driver for TCP.
>
>
> Hi,
>
> I forgot to tell you where you can find it:
> http://www.sparre.dk/unpublished/TCP.tar.gz
>
> If someone gets this working, I'm sure that
> Dave Grothe would like to add the driver to
> LiS.
>
>
> Best Regards,
>
> Ole Husgaard.
>
>
> Ole Husgaard wrote:
> >
> > Hi,
> >
> > I have released my old unfinished, kernel
> > crashing code under the GPL license.
> >
> > GPL is IMO needed for this, due to the close
> > interaction with the kernel, and should be no
> > problem with proprietary code, if you use
> > kernel modules.
> >
> > Please note that I haven't even looked at
> > this code for over a year, and haven't done
> > any STREAMS programming at all in this time,
> > so I may not be of much help if anybody wants
> > to pick up this work.
> >
> > Best Regards,
> >
> > Ole Husgaard.
>
--------------------------------------------------------------------------------
This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please immediately delete it and
all copies of it from your system, destroy any hard copies of it and
notify the sender. You must not, directly or indirectly, use, disclose,
distribute, print, or copy any part of this message if you are not the
intended recipient. PROTEK Network Management Group and each of its
subsidiaries reserve the right to monitor all email communications
through its network. Any views expressed in this message are those of
the individual sender, except where the message states otherwise and the
sender is authorised to state them to be the views of any such entity.
_______________________________________________
Linux-streams mailing list
[EMAIL PROTECTED]
http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
