× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




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




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.