SCTP Discussions

Text archives Help


RE: Re(2): [SCTP-Discussion] appropriate usage of echo_server/ech o_clien t and discard_server/t erminal demo programs


Chronological Thread 
  • From: Tuexen Michael <Michael.Tuexen AT icn.siemens.de>
  • To: "'discussion AT sctp.de'" <discussion AT sctp.de>
  • Subject: RE: Re(2): [SCTP-Discussion] appropriate usage of echo_server/ech o_clien t and discard_server/t erminal demo programs
  • Date: Wed Apr 4 16:01:01 2001
  • List-id: SCTP Discussions <discussion.sctp.de>

See my comments below.
Best regards
Michael

Michael Tuexen Tel.: +49 89 722 47210
Siemens AG Fax: +49 89 722 48212
ICN WN CS SE 51 E-mail:
Michael.Tuexen AT icn.siemens.de

> -----Original Message-----
> From: Yiwen Jiang
> [SMTP:Yiwen.Jiang AT tic.siemens.ca]
> Sent: Wednesday, April 04, 2001 3:30 PM
> To:
> 'discussion AT sctp.de'
> Subject: RE: Re(2): [SCTP-Discussion] appropriate usage of
> echo_server/ech o_clien t and discard_server/t erminal demo programs
>
> > 127.0.0.1 is the loopback address. The IP stack of a machine may use
> > this address to send packets to itself. What happens is that
> > if you send
> > a packet to 127.0.0.1, the IP stack will at once see that it
> > has received
> > the very same packet. And the packet will never be seen on
> > the network.!
> Agreed.
>
> > > Or to have the demo server to check to see if there is a
> > loopback address
> > > specified? Or, should this be done in the SCTP library?
> > Just that I can see
> > > people using 127.0.0.1 as server address without realizing
> > the consequences
> > > of it.
> >
> > Well, having that as a server address is surely nothing special,
> > but most people will know the consequences...
> But the problem I was having was when I use the loopback address to specify
> my server address, which in theory should work the same as if I specified
> the host IP address, does not behave that way.
>
> Maybe an example will help me explaining this... I did:
> on 10.20.2.30:
> %./echo_server -s 10.20.2.30 -V
> on 10.20.2.31:
> ./echo_client -s 10.20.2.31 -d 10.20.2.30 -V
>
> I can see not only the initial error infos, but also lines of output in the
> format of:
> 408925688: Data arrived (512 bytes on stream 0, ordered)
> 408925688: Data arrived (512 bytes on stream 0, ordered)
> on both the client and server screen.
[Tuexen Michael] Fine, that is how it should work.
> However, If I do:
> on 10.20.2.30:
> %./echo_server -s 127.0.0.1 -V
> on 10.20.2.31:
> ./echo_client -s 127.0.0.1 -d 10.20.2.30 -V
>
[Tuexen Michael] So there is no server running which accepts
packets for 10.20.2.30 or 10.20.2.31. So the behavior is OK. Using
the -s options means that you are accepting packets with that IP
address (and you will only use these addresses as source addresses. For this
the forwarding must be in tune with the parameters!).

> no data packets described above were displayed by either the server or the
> client. The only messages shown on both the client and server sides are
> error infos. If Current_error_log_ is set to 6, for example, I can see
> packets being dropped, especially on the client side. This is especially
> true for the discard_server/terminal program, because the client and server
> use different ports.
>
>
> So, I am guessing, when sending packets to a server, the client program
> uses the user provided server address in its SCTP header, and perform no
> translation if it is a loopback address. When server responds back to the
> client, it uses the provided source port number (including the source
> address) in the SCTP header with no interpretation. In this example, it is
> 127.0.0.1. So the server ends up replying to itself, rather than the client.
[Tuexen Michael] No translation is performed! Why should we.
You (as a user) must specify the right addresses.

> Of course, I could be completely wrong with this... But this reason is the
> only one I can think of that caused the above described behaviour... Maybe
> you could help me understanding the real cause?
>
> Thanks.
>
> Cheers,
>
> Yiwen
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion




Archive powered by MHonArc 2.6.19+.

Top of page