Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Winsock Questions (newbie)

Author
Message
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 27th Mar 2008 16:05
I've just started working my way through the 'getting started with winsock guide' on MSDN and I have a few basic questions.

1. To setup a UDP connection am I right in thinking that the hints data should be:


2. Am I right in thinking that I can't use the 'listen' command because this doesn't apply to UDP. For the server, after I've created a socket and bound it I am ready to receive data?

3. Am I right in thinking that the only commands involved directly in receiving and sending data are 'recv' and 'send'? There is no direct packet formulation commands in winsock, this has to be done manually?
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 27th Mar 2008 16:20 Edited at: 27th Mar 2008 16:23
UDP is connectionless. You can specify a specific address you want to receive packets from however, using connect.

You can create and bind UDP socket like this (after starting up Winsock of course):



After this you can call recvfrom to receive packets and obtain the address of the sender at the same time. If you associate the socket with a remote address (using connect) then you can just use recv.

Note that if you are sending data first (as a client) you don't need to bind, the first send/sendto you do will automatically do this.

Quote: "2. Am I right in thinking that I can't use the 'listen' command because this doesn't apply to UDP. For the server, after I've created a socket and bound it I am ready to receive data?"

Correct.

Quote: "There is no direct packet formulation commands in winsock, this has to be done manually?"

Correct.

Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 27th Mar 2008 19:14 Edited at: 27th Mar 2008 19:15
My first attempt at using 'recvfrom' hasn't gone too well. Here is the section of code that is causing trouble:


After pressing a key, the program freezes. This is after setting up a UDP listening socket called 'ListenSocket'. What am I doing wrong?

Full code so far is below just incase it will help you see where I'm going wrong:
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 27th Mar 2008 19:36 Edited at: 27th Mar 2008 19:41
As by default sockets work in blocking mode, certain operations will block until it can complete. In the case of recvfrom, it is waiting for data. Set your socket to non-blocking mode like this:



And then when using functions that would usually block, check for the WSAEWOULDBLOCK error which indicates that the operation would normally block, but has not due to the socket using non-blocking mode. If it was a receive operation, there is no data.

When data has been received, the function returns a value above zero (as indicated on the relevant function reference pages on MSDN).

Also, MSG_PEEK is considered bad practice, so I'd advise against using it. Always read as much data as possible at a time, to keep the internal buffer free.

You do not need to call WSACleanup if WSAStartup fails, as it never initialized anyway.

I'd also recommend that you either write a clean-up function or write some code at the bottom of the main function to clean up, so that you don't have to do several calls to do the same thing in every exit point.

Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 28th Mar 2008 14:25 Edited at: 28th Mar 2008 14:27
Quote: "Also, MSG_PEEK is considered bad practice, so I'd advise against using it. Always read as much data as possible at a time, to keep the internal buffer free."


According to the MSDN website, there are only 2 values for this parameter: MSG_PEEK and MSG_OOB. I tried using MSG_OOB but I get error 10045. It now works fine with MSG_PEEK in non blocking mode however.

A few more questions (hurray):

1. Am I right in thinking that on the server:
-There only needs to be 1 listening socket at any time.
-There needs to be as many sending ports as there are connected clients (each socket sending to a separate client).
-You can either send or receive on a socket, not both with UDP.

Or

-You can send and receive on a single socket with UDP.
-There is one main listening socket, which listens for initial data from newly connected clients.
-When data from a new client is found, a new socket is made for this client which sends and receives data from it there after.

2. Assuming that I'm not miles off with question 1 this means that I have to record what addresses I have sockets open to so that I don't end up making multiple unnecessary sockets for a single client.

The way the structures of winsock work is pretty confusing to me:
-If I call 'sockaddr_in SenderAddr' what exactly is this doing?
-Is data about addresses that sockets are connected to stored in a winsock structure, if so which one (I'm guessing its probably sockaddr)?
-How do I access the information in these structures i.e. how would I go about checking through all addresses that any sockets are currently connected to?

Thanks for all your help so far Benjamin.
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 28th Mar 2008 16:34 Edited at: 28th Mar 2008 16:56
Quote: "According to the MSDN website, there are only 2 values for this parameter: MSG_PEEK and MSG_OOB. I tried using MSG_OOB but I get error 10045."

They are optional (you don't have to specify any) flags you can pass to alter the behaviour. MSG_PEEK allows you to get a copy of the data without removing it from the internal buffer.

Quote: "-There only needs to be 1 listening socket at any time."

Correct, although in this case you have to check the sender of each packet to know who it's from.

Quote: "-There needs to be as many sending ports as there are connected clients (each socket sending to a separate client)."

Not sure what you mean by this. The remote port (which I assume you are calling the sending port?) is the local port of the other machine you're sending data to. Unless you meant sending sockets in which case you can do all communication through one socket.

Quote: "-You can either send or receive on a socket, not both with UDP."

You can do both.

Quote: "-If I call 'sockaddr_in SenderAddr' what exactly is this doing?"

It's declaring a sockaddr_in structure.

Quote: "-Is data about addresses that sockets are connected to stored in a winsock structure, if so which one (I'm guessing its probably sockaddr)?"

Yes, addresses are stored in a certain type of sockaddr structure. In this case it's sockaddr_in. You can use getsockname to get the address of a connected or bound socket.

Quote: "-How do I access the information in these structures i.e. how would I go about checking through all addresses that any sockets are currently connected to?"

Pass the address of a sockaddr_in structure to recvfrom, and when you receive a packet you can access the IP address and port in the sin_addr.s_addr and sin_port members, respectively. Don't forget that UDP is connectionless, so technically there's no such thing as a 'connected' UDP socket.

Here's a little console application that might explain some things:



Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 28th Mar 2008 17:16 Edited at: 28th Mar 2008 17:22
Sorry for the poor terminology, I think I meant sending sockets. Just to be sure though, I'll show you with the aid of some diagrams roughly what is going on inside my head.

I'm trying to work out what a server managing multiple clients using UDP does with sockets. Originally, this is how I imagined it works (based largely on guess work):


In the above diagram there are 3 clients involved. Client 1 and Client 2 have been sending and receiving data from the server for some time. New client has just joined.

In this diagram, whenever a packet is received on the listening port from a new client that does not have a sending socket, the server creates a sending socket and binds it to the IP of that client based on information from the recv command.

A sending socket is a socket that just sends information and a listening socket is one that just receives. When transferring data, all clients send data to the listening socket but only receive data from their assigned sending socket. So, sending socket 1 is closed if no data is received from client 1 after a certain period of time.

If we go forward in time by a few seconds (assuming everything remains the same), the server will assign a sending socket for New Client and the diagram will now look like this:


Now there are 2 assumptions that I've made:
1. You can only send/receive you can't do both on a single socket <- This is wrong
2. You can't bind multiple addresses to the same socket <- Not sure if this is right?

Taking 1. into account a better model to use would be:


This is an adaption using the same scenario as with the first diagram I mentioned. The only difference is that after the server realizes there is a new client, it creates a socket for the client to use which sends and receives rather than just sending.

To summarise
Can you bind multiple addresses to the same socket?
Does the third (final) diagram look like I'm going in the right direction?
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 28th Mar 2008 17:32
2nd diagram looks pretty but now you need to open more stuff up on the firewall. Hmm.

I think the first one is dead on. I could see doing it both ways... but you need to "Verify" Each UDP packet anyway... is the packet REALLY meart for you or some other system using the same protocol and port? So, might as well have one "gate" and one "Gate Keeper" right? I think Either Way COULD work. I don't know the details of the RULES for one socket versus needing two so I can't answer that question without a deep dive into the documentation and a few experiments of my own... but I always got the impression for UDP it's best to have the listener getting ALL PACKETS, and then send packets to whomever you need to. In a multi-threaded operation you might want something more robust but I don't know for certain.

I'm no expert here... so I'm probably wrong but that's my thinking anyways.

Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 28th Mar 2008 17:40
Quote: "Can you bind multiple addresses to the same socket?"

No, although I'm not sure what you mean by this. You can have sockets that have the same local address while having a different remote address. This is essentially what you want.

Quote: "Does the third (final) diagram look like I'm going in the right direction?"

Yes.

1. Create a listening socket to simply listen for new clients.

2. When data is received on the listening socket, create a new socket with the SO_REUSEADDR attribute (see setsockopt). Bind it to the same address as the listening socket (the address must be the same one the client sent data to), and then set the remote association with the client (ie. use connect on this socket, specifying the address of the client). By doing this, this new socket will only receive packets from this address, and will allow you to use the simpler send/recv functions. This should allow you to do what you want.

jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 28th Mar 2008 18:01
Quote: "this new socket will only receive packets from this address, and will allow you to use the simpler send/recv functions"


PERFECT!

Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 31st Mar 2008 14:51
So far as I understand: if the listening socket picks up information from a new client, it should create a new socket for use with that client. When creating a new socket I need to:
-Create a socket object for that socket by calling 'SOCKET'
-Create the actual socket (which is done with the 'socket' command)
-Bind the socket to the remote address of the new client

When creating a new socket object, it must have a unique name. How do I create a unique name without hard coding each name as 'Socket1', 'Socket2' etc.

These structures in winsock still confuse me. I'll explain what I'm trying to do using an example:
-I declare a sockaddr_in structure by calling 'sockaddr_in SenderAddr;'
-I use the recvfrom command to store the remote address in this SenderAddr structure.
-I then use the recvfrom command to store another remote address in this SenderAddr structure.

How would I access the stored information from the initial recvfrom call?
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 1st Apr 2008 17:20 Edited at: 1st Apr 2008 17:21
Good news! I have made some progress and I think I've got my head round winsock structures.

Client:
-Client connects to an IP specified by the user.
-Sends a packet every time user presses a key.


Server:
-Waits for packet on listening port
-When a new packet arrives:
-Checks if packet is from a 'new' user
-If it is, add it to a list of socketed users (will also give it a socket when I get that far)
-If it isn't then does nothing


Anyway, I still have the problem (hope I can work it out):
Quote: "So far as I understand: if the listening socket picks up information from a new client, it should create a new socket for use with that client. When creating a new socket I need to:
-Create a socket object for that socket by calling 'SOCKET'
-Create the actual socket (which is done with the 'socket' command)
-Bind the socket to the remote address of the new client

When creating a new socket object, it must have a unique name. How do I create a unique name without hard coding each name as 'Socket1', 'Socket2' etc."
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 1st Apr 2008 18:15 Edited at: 1st Apr 2008 18:15
Just a quick note, the term 'calling' refers to making a function call. You seem to be using it to refer to variable declarations. A declaration just makes space for a variable.

You'll be wanting to store the sockets in some kind of array or list, which depends on the way you want to store client data. Now that you're getting on to using multiple sockets, you might want to decide on an IO strategy. Simply checking for data on each socket works, but it's the least efficient way of doing it.

As for your problem, here's what you do (minus the error checking that should be present):

1. Create a socket:



2. Enable address reuse so that it can be bound to the same address as the listening socket:



3. Bind the socket to the local address:



4. Associate the socket with the remote address using connect:



After this you should be able to call send/recv on this socket to send and receive data with the client.

Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 1st Apr 2008 19:32 Edited at: 1st Apr 2008 19:34
Thanks

I have another problem , this is probably quite basic though. In the code I last posted things work fine when I'm running it locally using my local IP. When I have the server on my computer, and a client on another person's computer that is in a house nearby using the remote IP the client sends packets, but they don't get picked up by the server. Is there anything obviously wrong with the code above?

In non blocking mode & UDP, if a packet is sent but a recv command isn't used at the time it arrives, is it automatically dropped or does it wait in a queue and then when a recv command is used the oldest packet in that queue is returned?
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 1st Apr 2008 19:58
Quote: "Is there anything obviously wrong with the code above?"

Nothing that I can see, although I'd suggest hard-coding the IP address you want to listen on, to make sure the correct interface is being chosen. As long as the interface is correct, the router is forwarding the packets to your machine, and your firewall isn't blocking said packets, it should work.

Quote: "does it wait in a queue and then when a recv command is used the oldest packet in that queue is returned?"

Yes, it does this.

jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 1st Apr 2008 21:47
Quote: "a client on another person's computer that is in a house nearby "


(Only because it wasnt said) THAT person might have a firewall blocking it from getting to his/her Pc. Might need to open the PORT and on some routers - have the Open the PORT and specifically ALLOW the UDP packets through.

Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 1st Apr 2008 22:13 Edited at: 1st Apr 2008 22:26
Virtual server mode enabled:


and just to be sure, forwarded UDP port 27015 which is the port used in the code:


In this same scenario when using multisync, everything works fine. The client doesn't have a router. The client and server both have 'AVG Anti Virus Free' installed as well as windows firewall. The server has a router which is a 'BT Voyager 2100'. Both the client and server are connected via wires (no wireless).

Also worth mentioning, is that back in the days of trying to use dark basic pro's multiplayer commands, people could never connect to the server unless they were connected to my router. Would this indicate that my router doesn't like UDP, or is there something I can do to fix this problem?

[EDIT] I also tried hard coding the IP on the client, and the problem remains the same. So, the code for setting the IP was:
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 1st Apr 2008 22:59
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 1st Apr 2008 23:13
Just tried it with client and server's windows firewall disabled; same problem I'm going to google any problems people have had with my router tomorrow; it must be that.
Fasine
16
Years of Service
User Offline
Joined: 28th Mar 2008
Location:
Posted: 4th Apr 2008 05:07
Just a note: I had a problem with my program working and thought it was an issue with my friend's firewall, but I figured it out: when my computer disconnects from my wireless router (shuts down, etc.) its IP is no longer in use on the local network and can be assigned to another computer (in this case my parents') so I had to change the local IP the packets were being forwarded to since I was no longer xx.xx.xx.2, I'd been changed to xx.xx.xx.3. This might be your problem as well if you've disconnected from our network since the last time you had someone connect from another location.
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 4th Apr 2008 11:20
The IP's on my router only change when it is turned off and on, and this only happens when something goes wrong with it. I can't actually see a good reason why this shouldn't be working so I'm just going to assume it's my router for now since it has had trouble with DarkGDK in the past. When I get onto TCP, if that has the same problem then it must be my programming since multi sync works fine.

Anyway, I can't do anything for a week or 2, my main computer is broken
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 4th Apr 2008 14:32
Just a note - I'm no networking master but everytime I do a networking app or whatever - I'm pretty good while its all fresh in my head. I would go crazy if I had to fight the dynamic IP thing! Everything is fine - then - WHAT? Yeah... Get a Fixed IP when you get a Fixed PC Again. Less headaches. The more CONSTANTS in your configuration - the less to worry about.

Fasine
16
Years of Service
User Offline
Joined: 28th Mar 2008
Location:
Posted: 7th Apr 2008 08:23


Benjamin, I think I'm starting to get a hold of winsock commands. This is a UDP Client that I carved out of your example and made to go with a Server that is nearly identical to your example. Can you help me figure out why this code works with IP: 127.0.0.1 and yet when I change it to my internet IP, the server doesn't recieve the data? I thought the problem was my router, but I've got port forwarding for UDP packets on ports 1-65000 set up to be forwarded to this computer. So is there anything else in my code that might be messing this up? The Client is up top, and I've included the server below. Thanks again for all your help!

Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 7th Apr 2008 09:43
Fasine, is the client operating from outside of your LAN (Is the Client on a computer not connected to your router)? Is the server operating from within your LAN (Is it running on a computer connected to your router)?

If so (assuming that your code is correct), then it looks like you are having the same problem as me. Out of interest, what router do you have?
Fasine
16
Years of Service
User Offline
Joined: 28th Mar 2008
Location:
Posted: 7th Apr 2008 11:21
I'm running both the client and the server on the same computer, actually. My router is a Belkin, I don't know which model, but it's their low-end wireless router and I bought it about a year and a half ago. I'm actually sort of nonplussed as to why my code won't work with a real IP, unless there's something in the winsock structs that I don't understand (highly possible, they're bloody confusing.)
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 7th Apr 2008 11:26 Edited at: 7th Apr 2008 11:27
Quote: "but I've got port forwarding for UDP packets on ports 1-65000 set up to be forwarded to this computer."

I'd seriously recommend you only forward port 1337, particularly if there are other computers on your LAN.

If you're trying to listen for data over the internet then you need to listen on your LAN IP. Listening on the loopback address (127.0.0.1) will only allow communication between two applications on the same machine.

Also, you can't send data over the internet to yourself, so if both the server and the client are on the same LAN it won't work.

jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 7th Apr 2008 14:27
Nad my router - a linksys - with port forwarding etc... DROPS alot of stuff when I try to use the Internet IP (within my own network) it works but is intermittant - but if I use a machine outside my network - say from work - then its perfect. Don't know why - but because of this, all my TCPIP stuff I do with my webserver and my homemade webserver I use local IPs.. eiither 127.0.0.1 or the PC's IP (I don't use dynamic IPS) and it works great. Again, when I want to test from outside - its fine - internal - intermittant if I use the INTERNET fixed IP.

Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 7th Apr 2008 15:18
Apparently there is a small amount of routers that will deliver packets to the appropriate machine on the same network when the outgoing address is the router's address, although I wouldn't expect it to be intermittent.

jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 7th Apr 2008 16:24
Agreed - Imagine my Web Server I made. Each web page request can be a number of complete TCPIP connections and downloads (pictures etc within a web page) Each becomes its own thread, each is its own "communication".

Sometimes I'll get a lag - like the server is down, sometimes I get everything but a couple pictures, and usually a refresh or two might give the full page no errors.

Outside of my network - 100% reliable. Inside my network using IP's for my in house lan, 100% reliable. Using the URL's like www.jasonpetersage.com or www.jegas.com .. means a DNS look up etc - and this is where the intermittancy comes from but before saying DNS might an issue etc etc... if I use the actual "fixed IP" outside my network (My Internet Address) - I get the same situation.

This web server is faster (via benchmarks) than apache, IIS, Lighttp, and all the others I tested. So there isn't anything funny with my TCPIP code - it's quite responsive, fast to make use of my pool of reusable threads, to connect a port for responding to client request, spitting out data, and closing the connection.

So... I wouldn't expect intermittant either - but as is germain for Micheal, I would try some other network programs in a similiar way to see if its his lan, his pc, his router, or his wonsock code.

Actually Benjamin, with your help, his determination coupled with his "in-house" LAN success with his code. I don't suspect his CODE unles the 127.0.0.1 issue you mentioned is in play or he's messing up the IP address and it's working on a quirk due to some anomally like subnet mask and pure chance or some other unlikely thing - In short - I think its his LAN but he'll obviously need to check each link in the chain to be sure.

Fasine
16
Years of Service
User Offline
Joined: 28th Mar 2008
Location:
Posted: 7th Apr 2008 19:43
I'm actually able to communicate between my TCP client/server by using my Internet IP, so I'm not sure why it wouldn't work for UDP, but I'll try it on another computer and see how it works. Also: you mention that listening on the loopback address wouldn't work if I try to connect using my LAN IP. How would the code look different then? I thought that recv/recvfrom just pulled data from the buffer on a certain port? Won't any incoming packet destined for that port be stored in the buffer, regardless of its destination IP?
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 7th Apr 2008 19:46
Quote: "How would the code look different then?"

Just replace the occurrences of "127.0.0.1" with your computer's LAN IP.

Quote: "Won't any incoming packet destined for that port be stored in the buffer, regardless of its destination IP?"

Nope, when you bind the socket you are associating it with 3 things: protocol, interface (IP address), and port. If you associate it with the loopback address you will only get traffic on that interface.

Fasine
16
Years of Service
User Offline
Joined: 28th Mar 2008
Location:
Posted: 7th Apr 2008 21:54
Ah, I see what I was doing wrong now. So basically when I bind my server I'm saying "listen for UDP(protocol) packets destined for port 1337(port) on the machine with IP:1.2.3.4(interface) over my local network." Does this mean, then, that it's possible to accept packets sent to other computers on my network by using their IP instead? That's kinda scary, haha! Anyways, I got it working, it works using both my internet IP, my LAN IP, and it worked from my friend's computer and spit out his IP and port. The Client hasn't changed much, so I'll just put the server code up here in case it might help Michael out.
I never understood why I had to bind the socket before, but it makes sense from the perspective of my router just transmitting packets over the local network, and hoping that the computer with a matching IP/port accepts them. This would mean that in order to recieve any data, my program has to know what IP/port combination it should be looking for. I was also confused in that it was my local IP and not my internet IP I had to put in there, but the packets are all being forwarded to MY IP/port from my router, so they obviously wouldn't have the router's IP as their destination.

Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 7th Apr 2008 22:42 Edited at: 7th Apr 2008 22:43
Quote: "Does this mean, then, that it's possible to accept packets sent to other computers on my network by using their IP instead?"

I'm not a total expert on this but I believe the binding for the IP address is strictly to circumvent the possibility that the computer/server receives on more than one IP address. It's possible for a machine to use multiple NICs or single NICs and still accept input from more than one address. My email servers do it so that I can run multiple post office services on the machine and the same port.

However, it is also possible for a machine to open itself to accepting all packets that come across the same wire that it's on. I think it's called "slut mode."

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 7th Apr 2008 23:07
Quote: "Does this mean, then, that it's possible to accept packets sent to other computers on my network by using their IP instead?"

Nope, it doesn't allow this. It is possible to capture packets that aren't meant for the machine, but not this way.

Quote: "However, it is also possible for a machine to open itself to accepting all packets that come across the same wire that it's on. I think it's called "slut mode.""

Promiscuous mode. I prefer your name though.

Quote: "I never understood why I had to bind the socket before"

As Lilith said, it's possible for a machine to use multiple network interfaces (not just cards however), and binding chooses which one to listen for traffic on. When traffic reaches the machine, the OS checks if a socket is bound on that interface and port. If so, it places the data on that socket's buffer. If not, it discards it.

Fasine
16
Years of Service
User Offline
Joined: 28th Mar 2008
Location:
Posted: 8th Apr 2008 09:19
Alright, I've got my Client and Server talking to one another, so now I'm going through the process of switching over from console application to Dark GDK application, and when I try to build in "Release" mode, I get this error:

LIBCMT.lib(crt0.obj) : error LNK2001: unresolved external symbol _main

Any idea what might be causing this? It sounds like it's saying "where is your main() function?" but it knows that DarkGDK is an entry point, because it runs fine in Debug mode. I also tried compiling with the same settings (statically-linked, etc.) in my other game and had no problem, even with no main() function. Thanks again for all your help, guys!
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 8th Apr 2008 20:17
I'm throwing out a guess here. Bear in mind that your debug and release configurations are two different things. Make sure your release configuration has the location of the GDK lib file.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Fasine
16
Years of Service
User Offline
Joined: 28th Mar 2008
Location:
Posted: 8th Apr 2008 23:42
Ah, figured it out. My Subsystem wasn't set to anything, and I guess it thought that if I was using winsock, it was probably a console app so I should have a main(). Setting it to a Windows app fixed it, now it compiles fine! Odd that this problem only occurred when I statically linked the build (that was apparently the difference between Debug and Release)
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 9th Apr 2008 18:43 Edited at: 9th Apr 2008 18:52
Well, I found some time to try some more winsock and I've run into a problem creating a socket for each client. I get error 10047 (WSAEAFNOSUPPORT) when trying to use the connect command.
Quote: "An address incompatible with the requested protocol was used. All sockets are created with an associated "address family" (i.e. AF_INET for Internet Protocols) and a generic protocol type (i.e. SOCK_STREAM). This error will be returned if an incorrect protocol is explicitly requested in the socket call, or if an address of the wrong family is used for a socket, e.g. in sendto."


The code where 'connect' is used:


Full Server Code ('Connect' is used in here):


Full Client Code:
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 9th Apr 2008 18:57
You're not passing the address of the sockaddr_in structure properly, you're passing the address to one of its members. It should be:



Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 9th Apr 2008 19:08
silly me. The problem is not solved however, the same error occurs even after correcting that mistake.

The code where 'connect' is used:


Full Server Code:
Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 9th Apr 2008 20:02 Edited at: 9th Apr 2008 20:03
[edit] Disregard this post...

Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 9th Apr 2008 20:02
Ah, I found the problem. When saving 'new client' information, I was only saving the address, not the port or any other information that was needed.

For reference, here is the fixed code for the server:

Benjamin
21
Years of Service
User Offline
Joined: 24th Nov 2002
Location: France
Posted: 9th Apr 2008 20:02
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 10th Apr 2008 19:47 Edited at: 10th Apr 2008 19:51
Back to the age old problem I have of getting packets from outside of my router. Note that where 'server exe' is mentioned, this is simply the compiled code mentioned in previous posts for the server:

I tried sending packets from a computer connected to my router as a client, to another computer connected to my router as a server using local IP's (192.168.1.6). The results were that packets were received by the server as should be.

I tried sending packets from a computer connected to the internet, not via my router as a client, to a computer connected to my router as a server. Packet sniffing tools picked up nothing from the client's external IP (172.212.250.207) on the server and the server exe also picked up nothing.

I tried sending packets from a computer connected to my router to that same computer using the remote IP address (81.154.10.252) of my connection that has all ports forwarded to the computer's IP (192.168.1.6). Packet sniffing tools picked up the following each time a packet was sent but the server exe picked up nothing:


The first two rows represent data that has been sent out and the last row represents data that has been received.

What do you think all this means?

Attachments

Login to view attachments
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 10th Apr 2008 19:54
Have you tried running a tracert to the destination to see if you've got a broken jump somewhere?

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 10th Apr 2008 20:04 Edited at: 10th Apr 2008 20:16
What is a tracert?

[edit] Forgot about google...

These are the results of a tracert I just did:


Here is another tracert test I did:
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 10th Apr 2008 20:13
Quote: "What is a tracert?"


tracert is done from cmd mode. You just type in

tracert 81.154.10.252

This should present you with a list of the hops to your destination. It also includes timing indications of what kind of response time you're getting from each hop. If there's a breakdown somewhere along the way you should get some indication where it is and maybe some information like "host unreachable" or "request timed out." It may not help but it's a start.

tracert is a short name version of the Unix traceroute command. You can also use domain names in addition to the pure IP address.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 10th Apr 2008 20:19 Edited at: 10th Apr 2008 20:20
Ah okay, here are the results. So far as I can see, it looks quite good:

Attachments

Login to view attachments
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 10th Apr 2008 20:22
I just noticed your packet capture showed "port unreachable" That probably means the machine is reachable but it's not allowing communication on that port. Is it a firewall problem on the destination machine?

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Michael P
18
Years of Service
User Offline
Joined: 6th Mar 2006
Location: London (UK)
Posted: 10th Apr 2008 20:26
I don't think so, I've done tests with firewalls disabled and nothing has changed.

Login to post a reply

Server time is: 2024-09-29 21:31:22
Your offset time is: 2024-09-29 21:31:22