server and client's port number doesnot match

[dev]

hello all,

i am using SOCK_STREAM,PF_INET, the server listens at port 2500,(server is on windows,uses winsock.h), and client is on SCO unix, that too on a terminal using telnet, so when server reads a message from client and when client sends a message, both prints the details as:-
-server prints the address and port of client
-client prints address and port of server it is connected to
the address matchs but not the port numbers?, y?
the data transfer is perfectly fine, and all else works fine.

[RobSeace]

Well, one wouldn't expect the client's port# to match the server's
listening port#... There's no reason they should match...

[dev]

hello sir,

i am printing the port number of client( assinged dynamically at the time of connect() call) from client
and
the server prints the port number of client( recived by the accept() call) connected, so should not they match?,

(client is on unix and server on windows)

[RobSeace]

That's not what you said initially: you said the client was printing the
IP and port# of the server it connected to, not its own local IP and port#...

But, if it's really printing its own local IP and port#, then yes, it should
match what the server sees at accept() time... If it's not, you'll have to
explain a bit more how they differ (what is each side printing, exactly?),
and how you obtain the addresses on each side (presumably, you do
getsockname() on the client after connect(), and either just get the
addr from accept() or do a getpeername() on the server)... Or, preferably,
just post the code you're using...

[dev]

hello Rob,

again it was my stupid mistake. i didnot convert/cast the port numbers using ntohs before printing the port number. so now it worked. what exactly is the use of ntohs and htons?

with thanks
dev

[RobSeace]

ntohs()/htons() and ntohl()/htonl() are for converting ints (a short or long,
hence the trailing "s" or "l") to/from host/network byte-ordering... Network
byte ordering is always big-endian, while host byte ordering varies
depending on your system... (But, Intel x86 machines, for instance, use
little-endian byte-ordering...) So, they're just needed to make sure that
hosts with different byte-ordering can interoperate with each other... All
hosts send ints in network byte order, and then receiving hosts convert
them back to host byte ordering for whatever manipulation they need to
do on them...

[dev]

hello Rob,

thanks for the help.


dev