Chronological Thread 

< Chronological >      < Thread >

---

> 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.

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

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.


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

---

• RE: Re(2): [SCTP-Discussion] appropriate usage of echo_server/ech o_clien t and discard_server/t erminal demo programs, Tuexen Michael, 04/04/2001
  • <Possible follow-up(s)>
  • RE: Re(2): [SCTP-Discussion] appropriate usage of echo_server/ech o_clien t and discard_server/t erminal demo programs, Yiwen Jiang, 04/04/2001
  • RE: Re(2): [SCTP-Discussion] appropriate usage of echo_server/ech o_clien t and discard_server/t erminal demo programs, Tuexen Michael, 04/04/2001
  • RE: Re(2): [SCTP-Discussion] appropriate usage of echo_server/ech o_clien t and discard_server/t erminal demo programs, Yiwen Jiang, 04/04/2001
  • RE: Re(2): [SCTP-Discussion] appropriate usage of echo_server/ech o_clien t and discard_server/t erminal demo programs, Tuexen Michael, 04/04/2001

---

Archive powered by MHonArc 2.6.19+.