Mike Mullikin wrote: No, I was joking. I found it humourous that you were a Corel software developer who admittedly didn't code very well. I think he was saying he doesn't like his *current* job because he doesn't get to code....

Damn that is a big number.

I don't this approach will do any good. The reason is the dialog is created on the stack, which you stated correctly. However, since it's created on the stack it will also be destroyed when the function exits. So you'll never see the dialog. Do a search for a lesson on multiple dialogs, but it amounts to catching the "close" messages and calling 'delete' on the right pointer. This will free the memory allocated (like you said).

s_k wrote: How can I get IP address from client socket which I accepted ?? With Berkeley sockets you need to pass a sockaddr_in struct to your accept() call like so: struct sockaddr_in their_addr; /* connector's address information */ /* create a socket and call bind() and listen() */ sin_size = sizeof(struct sockaddr_in); new_fd = accept(sockfd, &their_addr, &sin_size); Upon connection you can read the values from the their_addr struct and get what you need. As for your other question I personally can't answer it in the context of a forum post. I would just look at how other programs handle rules like that for guidance. It's the kind of thing you can make as complex as you want, but I would really strive for simplicity to reduce logic errors.

Heh, I fear this is a case where you have too many "unique" details for me to be much help. It seems like you get the drift of what I was saying, but it doesn't directly apply to you. :(

Dave_ wrote: The application is not actually a server. There are two threads, one for sending, and one for receiving. This is fine and makes sense. Dave_ wrote: When the PC sends a message, it will send using a constant source port number of 1594. This does not. The source port number applies when you are *sending* a message and should be determined by the operating system when you create the socket. This should not be a constant. The reason is you have no way of knowing (realistically) what ports are being used, so the OS takes care of it for you. To help clarify: 1. Computer A wants to send a message to computer B 2. Computer B binds to a port (say 2000) 3. Computer A opens a socket connection to B and the OS assigns it a port of 47826 (essentially random from A's point of view) to use 4. Computer A sends a message to port 2000 on B Now, from A's point of view, 2000 is the *destination* port, and 47826 is the *source* port. Dave_ wrote: I don't understand how I could possibly be recieving messages if when I pass in IN_ADDRANY, and 0 for the port number, and that results in a port number 1679 (for example) after the bind, since most messages (if not all) are coming in on port 1594? See, if your messages are coming in on port 1594 then your server must be listening on the same port to receive them. That's why, for the receiving computer, it doesn't make sense to dynamically let the OS determine the port to bind to. You'll want to explicitly bind to port 1594, not 0. Forgive me if I'm missing something, but I hope that clears up what I'm trying to say.

Dave_ wrote: When my listening socket binds to IN_ADDRANY, and I pass port 0 to the bind call, doesn't that mean that I can rcv messages from any port number? This should be true, since this is the part that has been working for quite a while. No, that's not correct. When you recieve a message you must use, aka bind to, a port number known to both computers ahead of time. The reason is the client (or sending machine) must know which port to send its message to. The server can only listen on one port at a time. Like someone else pointed out, pick some high random number (below 65535 though) so you don't interfere with ports that have official uses ( those < 1024). It's like a telephone number. When someone calls you they must know your phone number. You don't care what number they're calling from (that's where IN_ADDRANY comes from), but you'll always be to receive calls at your number. Don't feel estranged.... socket programming is pretty goofy when you first start doing it.