SCTP protocol connect() question

Hi

I'd read about the new SCTP protocol and decided to implement a simple telnet
like client program for it. This seemed to work ok except for one minor issue.
Unfortunately I can't send the people working on the kernel sctp code
an email without becoming a member or sourceforge so I thought I'd post
my problem here.

It seems that the remote server does not receive a connect notification
at the sockets API level until the client has done a connect() AND sent
some data down the socket. Is this the correct/default behaviour (ie having
to send data for the connect to succeed) or is this a bug in the kernel or
sockets library? I'm running 2.4.23 on a slackware 9 distribution.

Thanks in advance for any help.

B2003

(E-Mail Removed) wrote:
> It seems that the remote server does not receive a connect notification
> at the sockets API level until the client has done a connect() AND sent
> some data down the socket. Is this the correct/default behaviour (ie having

No, it's not. The server should be doing a listen and accept fork/loop.
The client merely needs to do a connect (and then will want to call
setsockopt on success).

> to send data for the connect to succeed) or is this a bug in the kernel or
> sockets library? I'm running 2.4.23 on a slackware 9 distribution.

Well, it doesn't happen here under 2.4.22, glibc 2.1. Are you sure that
you eat up all the characters at the end of the previous connection? Or
something like that?

Peter

(E-Mail Removed) (P.T. Breuer) wrote in message news:<(E-Mail Removed)>...
> (E-Mail Removed) wrote:
> > It seems that the remote server does not receive a connect notification
> > at the sockets API level until the client has done a connect() AND sent
> > some data down the socket. Is this the correct/default behaviour (ie having
>
> No, it's not. The server should be doing a listen and accept fork/loop.
> The client merely needs to do a connect (and then will want to call
> setsockopt on success).

Which particular socket option? Is this required for a complete connect?

>
> > to send data for the connect to succeed) or is this a bug in the kernel or
> > sockets library? I'm running 2.4.23 on a slackware 9 distribution.
>
> Well, it doesn't happen here under 2.4.22, glibc 2.1. Are you sure that
> you eat up all the characters at the end of the previous connection? Or
> something like that?

No , this is on the initial connection having started up new processes. I've
double checked everything , can't see any fault. Maybe the option makes
the difference?

B2003

Boltar <(E-Mail Removed)> wrote:
> (E-Mail Removed) (P.T. Breuer) wrote in message news:<(E-Mail Removed)>...
> > (E-Mail Removed) wrote:
> > > It seems that the remote server does not receive a connect notification
> > > at the sockets API level until the client has done a connect() AND sent
> > > some data down the socket. Is this the correct/default behaviour (ie having
> >
> > No, it's not. The server should be doing a listen and accept fork/loop.
> > The client merely needs to do a connect (and then will want to call
> > setsockopt on success).

> Which particular socket option?

Up to you.

> Is this required for a complete connect?

Don't be silly! Anyway, you've already connected.


> No , this is on the initial connection having started up new processes. I've
> double checked everything , can't see any fault. Maybe the option makes
> the difference?

No.

Provide the simpleset example of your code possible. About 10 lines.

Peter

(E-Mail Removed) (P.T. Breuer) wrote in message news:<(E-Mail Removed)>...
> Boltar <(E-Mail Removed)> wrote:
>
> > Is this required for a complete connect?
>
> Don't be silly! Anyway, you've already connected.

Well I didn't think so but you can never take anything for granted in
programming

>
>
> > No , this is on the initial connection having started up new processes. I've
> > double checked everything , can't see any fault. Maybe the option makes
> > the difference?
>
> No.
>
> Provide the simpleset example of your code possible. About 10 lines.

The client I wrote (modified an old program of mine to do SCTP) is available
here (the code is too spread out to post the relevant bits in this message):

http://www.ogham.demon.co.uk/zips/scl.c

The relevant server code is:

/* initialize sockets */
printf("Initialising sockets on port %d\n",PORT);
size=sizeof(struct sockaddr_in);
#ifdef SCTP
if ((listen_sock = socket(PF_INET,SOCK_STREAM,IPPROTO_SCTP)) == -1) {
#else
if ((listen_sock=socket(PF_INET,SOCK_STREAM,IPPROTO_T CP)) == -1) {
#endif
perror("socket()"); exit(1);
}

/* Allow reboots even with TIME_WAITS etc on port */
on=1;
setsockopt(listen_sock,SOL_SOCKET,SO_REUSEADDR,(ch ar *)&on,sizeof(on));

bind_addr.sin_family=AF_INET;
bind_addr.sin_addr.s_addr=INADDR_ANY;
bind_addr.sin_port=htons(PORT);
if (bind(listen_sock,(struct sockaddr *)&bind_addr,size) == -1) {
perror("bind()"); exit(1);
}
if (listen(listen_sock,20)==-1) {
perror("listen()"); exit(1);
}
:
:
:
accept_sock=accept(listen_sock,(struct sockaddr *)&acc_addr,&size);
printf("Connect on socket %d\n",accept_sock);
:
:
:


Hope that helps.

Thanks for your time btw.

B2003

Boltar <(E-Mail Removed)> wrote:
> (E-Mail Removed) (P.T. Breuer) wrote in message news:<(E-Mail Removed)>...
> > Provide the simpleset example of your code possible. About 10 lines.

> http://www.ogham.demon.co.uk/zips/scl.c

(I'll trim a bit here)

> The relevant server code is:

> size = sizeof(struct sockaddr_in);
> if ((listen_sock=socket(PF_INET, SOCK_STREAM, IPPROTO_[S]TCP)) == -1)
> exit(1);


Uh, I use AF_INET, not PF_INET. Maybe it's the same! Yours is
notionally correct.


> /* Allow reboots even with TIME_WAITS etc on port */
> on=1; setsockopt(listen_sock,SOL_SOCKET,SO_REUSEADDR,&on ,sizeof(on));

OK. You may also wish to set the socket nonblocking with fcntl, in
order to subsequently facilitate the immediate detection of and reaction
to errors.

> bind_addr.sin_family = AF_INET;
> bind_addr.sin_addr.s_addr = INADDR_ANY;

That is a 0, no?

> bind_addr.sin_port = htons(PORT);

Looks fine.

> if (bind(listen_sock, &bind_addr, size) == -1)
> exit(1);

Correct.

> if (listen(listen_sock, 20) == -1)
> exit(1);

OK. Queue of 20.

> accept_sock = accept(listen_sock, &acc_addr, &size);

Looks fine. I run a select loop with timeout first, in order not to be
stuck forever in an accept, but that's taste.


> Hope that helps.

At first glance that looks completely normal.

Must be the client.

Peter

(E-Mail Removed) (P.T. Breuer) wrote in message news:<(E-Mail Removed)>...
> At first glance that looks completely normal.
>
> Must be the client

ANy chance you could post the relevant parts of your client so I can compare
it with what I've done?

Thanks

B2003

Boltar <(E-Mail Removed)> wrote:
> (E-Mail Removed) (P.T. Breuer) wrote in message news:<(E-Mail Removed)>...
> > At first glance that looks completely normal.
> >
> > Must be the client

> ANy chance you could post the relevant parts of your client so I can compare
> it with what I've done?

You want a random tcp client? I don't have a simple one. Look at telnet
code. As far as I can see, the sequence in my codes is


sock = socket (AF_INET, SOCK_STREAM, IPPROTO_TCP));

...
hostn = gethostbyname (hostname);
addrin.sin_family = AF_INET;
xaddrin.sin_port = htons (port);
xaddrin.sin_addr.s_addr = *((int *) hostn->h_addr);
...

if (connect (sock, (struct sockaddr *) &xaddrin, xaddrinlen) < 0) {
err ...
}

setsockopt ..

and that's it.


Peter

(E-Mail Removed) (P.T. Breuer) wrote in message news:<(E-Mail Removed)>...
> Boltar <(E-Mail Removed)> wrote:
> > (E-Mail Removed) (P.T. Breuer) wrote in message news:<(E-Mail Removed)>...
> > > At first glance that looks completely normal.
> > >
> > > Must be the client
>
> > ANy chance you could post the relevant parts of your client so I can compare
> > it with what I've done?
>
> You want a random tcp client? I don't have a simple one. Look at telnet
> code. As far as I can see, the sequence in my codes is

No, I was hoping for the SCTP specific part. The TCP part of my client works
fine, its the SCTP bit that seems to have this glitch.

B2003

Boltar <(E-Mail Removed)> wrote:
> (E-Mail Removed) (P.T. Breuer) wrote in message news:<(E-Mail Removed)>...
> > Boltar <(E-Mail Removed)> wrote:
> > > (E-Mail Removed) (P.T. Breuer) wrote in message news:<(E-Mail Removed)>...
> > > > At first glance that looks completely normal.
> > > >
> > > > Must be the client
> >
> > > ANy chance you could post the relevant parts of your client so I can compare
> > > it with what I've done?
> >
> > You want a random tcp client? I don't have a simple one. Look at telnet
> > code. As far as I can see, the sequence in my codes is

> No, I was hoping for the SCTP specific part. The TCP part of my client works
> fine, its the SCTP bit that seems to have this glitch.

I'm sorry - until I just looked it up, I had no idea what SCTP is. Nor
do I have any idea at the moment how it is supported in linux, or if it
is supported. However, your examples made it appear as though one
simply opens a socket with a particular (new) protocol specifier.

How does one specify which stream going through the socket is which?
(No, I am not going to read the RFC this early in the morning).


Peter