Winsock and select()

[juansta]

I have an application where Im using Winsock...

I use two ports, one is for general control, and the other is only opened/used for large data transfers.

Now, when I use the application on my local network, everything works as expected. However, when I try and use it via a remote network (WAN) the large transfers dont seem to work... Application times out on a select() call - Waiting on activity on a socket... No actual error, just a timeout.

the control port works as expected, and some handshaking works on the data port - at the begining of transfers, but when I start to send data, no data is received (sending from the other end is ok)

I have configured my router, and assume it is configured correctly as there is data being let through in both cases (control and handshaking)...

What else could be wrong here? Any thoughts...

Im stumped as it works perfectly from within a local network... ????

[henky@nok.co.id]

If your program runs well in local network environment, it will run in WAN too.
Check firewall setting. Probably your data port is not allowed to pass through.

[juansta]

That's what I thought originally...

But some control and handshaking occurs OK in the newly opened port... Only the "large" (1Kb) transfers never reach their destination using WAN...

Im going to triple check, but in escense, if it works in LAN, it will work through WAN? So my code is correct? just need to sort out the router... ? Sick of chasing my tail here...

[MikeAThon]

So my code is correct?
If at least some of your transmissions are getting through the routers and firewalls, then the network architecture is fine, and it's probably incorrect code.

In sockets, most coding errors show up only when run over an actual network, since only then is there actual network delay and routing. The delay and the routing will cause most network functions to perform differently, as compare to the performance on the loopback address or on a LAN. For example, a send() function that completes correctly on a local machine will fail with "only some of the data was sent" errors when run over a WAN. Likewise for recv(), i.e., only some of the expected data was actually received.

Make certain that your code checks the returned value for every socket function, and if the returned value is not the expected value, make certain that you call WSAGetLastError() immediately, to determine why the function did not complete as expected. For example, on a send(), you expect all bytes in the buffer to be sent. send() will tell you how many bytes were actually sent, so compare the two, and call WSAGetLastError() if they are different. Same for recv(). Especially for recv().

Mike

PS: If you are using TCP, please confirm that you understand that TCP is a stream-based protocol and not a message-based protocol, and that you understand the implications of this distinction.

[juansta]

yep, I understand that it is a stream-based protocol... But to be honest this is my first slash at something like this.

My messages are setup with headers, which include the message size. Im my receiving code, I loop until all bytes are received (with the size in accordance with what the message header tells me) I wasnt aware that sending the data may also require this approach.

I'll re-check my error handling, and the above.

Thanks for the help!

[MikeAThon]

... My messages are setup with headers, which include the message size. Im my receiving code, I loop until all bytes are received (with the size in accordance with what the message header tells me)
This is good. Also be certain that you loop while receiving the header, since it too might not be received completely in a single call to recv().

I wasnt aware that sending the data may also require this approach.
Yes, although in truth, partial sends are encountered far less frequently than partial receives. But even though they are inffrequent, they can still happen, and you need to check for partial sends too.

Mike

[henky@nok.co.id]

In sockets, most coding errors show up only when run over an actual network, since only then is there actual network delay and routing.

Yes. You're right Mike.
I started from assumption that juansta's codes consider about the delay.
Firewall setting is one of possibility cause. My assumption is like this:
Port of control socket: 1000
Port of data socket: 5000
Probably firewall allows port 1000, but not allow port 5000.
Though handshaking is success (because using allowing port), but when
transferring data will fail.