Re: Sockets problem -- RPG400-L


On Mon, 22 Apr 2002 Ron@cpumms.com wrote:
>
> Scott,
>
> I don't know if you saw my original post, listing the apis we are calling
> so I'll post them here again.

Yes, I saw them, but they didn't tell me anything.

> This code works well for other socket connections, but this is the first
> time we've connected with a server that is handing off the connection so
> I wasn't sure if there was a piece I was missing.

It depends on what your vendor means by "handing off the connection".
Normally you don't have to do something special.  Maybe in this case, you
do.  Without any docs, it's really hard to tell!

> I'm glad to hear you say that the handoff is invisible to the
> client, because thats the way i understood it to be also.

I said that *NORMALLY* the handoff is invisible.  There are exceptions.

> I just noticed we  are doing a WRITE instead of a SEND (but our
> programmer says she's tried it both ways and neither works).

Yeah, you can use write() instead of send().  It really doesn't matter
unless you need to send out-of-band data.

>
> ** Set socket descriptor to be reuseable.
>       c             EVAL      RtnCd = SetSockOpt(SrvrSktId
>       C                                               :SOL_SOCKET
>       C                                               :SOL_REUSEADDR
>       C                                               :%ADDR(On)
>       C                                               :%SIZE(On))

this is the the only strange thing that you're doing.   Normally you
only set SOL_REUSEADDR on the server side, not on the client side.
I don't see why it would matter, though.


> Here's what the vendor told us to do:
>
> Looking at what should be done at CPU's side, the logic should be:
>
> // Create an unconnected socket for TCP/IP
> m_Sockfd = ::socket(AF_INET, SOCK_STREAM, 0);

This matches what you're doing exactly.   It's not terribly helpful,
it's just telling you that it's a "stream" socket in the "internet
protocol" address family.  In other words, it's TCP over IP.

>
> // Connect to serv_addr (207.230.238.11, 5550) and
> // set m_Sockfd to some unique value (e.g., 34567)
> connect(m_Sockfd, (struct sockaddr*)&serv_addr, sizeof(serv_addr));

Aside from the fact that the comment is blatantly WRONG (this does not set
m_Sockfd to anything -- that's done by the socket() call above) this code
is unhelpful.

At least, in Windows 3.1, Windows 95, 98, ME, NT, 2000, XP, BSD4.2,
BSD4.3, BSD4.4, and all BSD derivatives, Linux and Linux derivatives,
and OS/400 it does not change the value of m_Sockfd.   I'd be very, very
surprised to find out that something else does.   At any rate, it doesn't
matter at all since this number is never communicated with the server!
It's just a number used by your program to let the OS know which socket
you're referring to.

All this code appears to be doing is trying to tell you how to connect
a TCP socket to a remote system.

>
> // Send messages to 34567
> send(m_Sockfd, outBuffer, ::strlen(outBuffer), 0)
>

That's not terribly helpful.   what do you put into outBuffer?   How do
you know what goes into it?   What can you expect to get back?  etc.

These are the things you need to know!   The question isn't "How do I use
sockets" but rather "how do I use your server?"


>
> Presumably, they'll be using the above calls (BSD sockets API).
>

Those above calls are for implementing a client -- not a server.  Even
if they were for a server, they don't tell me anything but how to connect
the socket.

Once you're connected, what do you need to do?   What are you allowed to
send?  What are the expected responses?   That's called the
"application-level protocol".