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



I probably wasn't as clear as I should have been.  The program continues on 
after the connect, but it never actually connects. It just doesn't report an 
error. Also, the next thing that happens is the attempt to send data, which 
also appears to succeed and then the program ends normally.

However, after reading your reply, I am pretty sure that the reason why no 
errors are reported are because I am using a router (Linksys wireless router) 
which has a built in firewall. On that router, I am doing port forwarding to 
open up the port that I want to listen on with the socket server.  Based on 
what you said, I am guessing that the firewall is not reporting an error on the 
socket connect and that's what's causing the lack of a failure 
indicator/message.

I can't believe how incredibly complex commuications prograqmming can suddenly 
become!

Thanks for your response!

Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx> wrote: >         C                   
if        connect(sock: p_connto: addrlen) < 0
>         c                   eval      msg = 'unable to connect to server!'
>         c                   dsply                   msg
>         c                   callp     close(sock)
>         c                   return
>         c                   endif

(shudder).  A few problems with the code (they're probably my fault, 
actually):

a) If connect() fails, you never deallocate the memory that was allocated 
with ALLOC.  That means there's a memory leak.  (If I had the time to 
re-write that tutorial, I'd remove all of the ALLOC statements and use 
LIKE(sockaddr) to define memory for socket address structs.)

b) That code doesn't give a meaningful error message.  It should be 
checking errno and reporting the error message using strerror().  However, 
you probably copied the code from CLIENTEX1.  In that tutorial, I tried to 
only teach one thing at a time, so I teach you how to call the APIs, then 
I teach you error handling later.  (Unfortunately, lots of people stop 
before they get to error handling.)

However, it doesn't make sense that the connect() call would succeed if 
there's no server listening for connections.


> and it works fine.  The problem is that it shouldn't work because I do 
> not actually have a socket server listening on the port I specify in the 
> SIN_PORT paramater. That is, if I use a port # of 8540 in SIN_PORT for 
> example but my socket server is actually listening on port 3994, then I 
> should get an error, right?  But I don't. Instead, I get the return 
> value = 0 and the program continues on.

That doesn't make sense.



> If it makes a difference, my socket server is running on a pc and I use 
> the DOS command NETSTAT -a to see what is active on all the ports.  I 
> see my socket server listening on port 3994 and nothing on 8540, and yet 
> the connect does not return a negative value.

Are you sure you're connecting to the correct IP address?  Maybe you're 
connecting to a different computer, and that computer happens to have 
something that's listening to port 8540.

After the connect() is successful, can you open up another 5250 window and 
use NETSTAT *CNN (on the iSeries that your RPG program runs on) to see if 
the connection is established?

Is there a firewall or proxy server involved that might be tampering with 
the connection?  Frequently, companies will block ICMP for security 
reasons (IMHO, that's a misguided choice).  When they do this, it makes it 
impossible for the remote computer to report errors.

Is there a chance that your prototype for connect() is wrong?

I have to admit that I've never had the problem you're describing. The 
stuff above is the only stuff I can think to try.  If the suggestions 
above don't help you, can you tell me how to reproduce the problem?



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.