.
Pages: 12
You're not very clear. If you want help on a specific point, you need to be clear. I apprciate that English may not be you native language.
The only difference between a UDP client and server is than the server binds to an endpoint so it can be found. The server just responds to the sender on whatever endpoint they come in on.
So if your client was assigned port 29005, that was assigned by the network stack. If you restart the client, you'll likely get a different port as its a different endpoint. If you want to keep the port, don't close the socket until your done.
The only difference between a UDP client and server is than the server binds to an endpoint so it can be found. The server just responds to the sender on whatever endpoint they come in on.
So if your client was assigned port 29005, that was assigned by the network stack. If you restart the client, you'll likely get a different port as its a different endpoint. If you want to keep the port, don't close the socket until your done.
You can't tell that your server sends data to your port. A server is something that answers to data sent by a client.
You can if you want have your local computer as a client to send data on a port of a server, and be server waiting for incoming connection from a remote client on a local port. Those two can have the same port number (since one is a remote port and one is a local port), but they will be done with two differents sockets
You can if you want have your local computer as a client to send data on a port of a server, and be server waiting for incoming connection from a remote client on a local port. Those two can have the same port number (since one is a remote port and one is a local port), but they will be done with two differents sockets
I send data from my port 29005 to a server. The client has 29005? How did it obtain this port?
Server send me another information. I send back to the server another information.
So here my socket is close. The client closes the socket? Or was it the server?
Another server with other ip and port, send me to my port 29005. I thought the client port was closed?
When I received this data, I must send back to this server information.
How I detect when this secondly server send to me some information? If the client is still open and listening on 29005, recvfrom should be sufficient.
I'm really lost. Can you answer the questions? It's not at all clear to me what you're saying, you're not using any nouns.
Server send me another information. I send back to the server another information.
So here my socket is close. The client closes the socket? Or was it the server?
Another server with other ip and port, send me to my port 29005. I thought the client port was closed?
When I received this data, I must send back to this server information.
How I detect when this secondly server send to me some information? If the client is still open and listening on 29005, recvfrom should be sufficient.
I'm really lost. Can you answer the questions? It's not at all clear to me what you're saying, you're not using any nouns.
When your UDP server starts up, you create a socket. At this point it's not bound to an endpoint.
Then you call bind to bind that socket to an endpoint (network address/port). You need to do this so other network services can find the service.
Some client somewhere wants to use that service so it creates an unbound socket, fills in a sockaddr_in with the network address/port of the server, and uses it in
If the server wants to reply to the client, it just uses the address that the request came in on. That's why
If the client closes the socket, the session is considered closed. That port is returned to the free pool.
If you want to guarantee the address/port the the client uses, you must bind the socket to it in the same way the server does. There's nothing stopping you from doing that. You then have peers that service requests in their own right.
It's tricky trying to discuss implementation issues without knowing the architecture, or what you're trying to achieve.
Then you call bind to bind that socket to an endpoint (network address/port). You need to do this so other network services can find the service.
Some client somewhere wants to use that service so it creates an unbound socket, fills in a sockaddr_in with the network address/port of the server, and uses it in
sentto to send something to that endpoint. When you do that, the network stack assigns you an address that is then bound to your client socket. The address is based on the route IP used and the port is randomly assigned. Some stacks are better at random assignments than others. OpenBSD is a good one, Windows less so.If the server wants to reply to the client, it just uses the address that the request came in on. That's why
recvfrom also returns an address.If the client closes the socket, the session is considered closed. That port is returned to the free pool.
If you want to guarantee the address/port the the client uses, you must bind the socket to it in the same way the server does. There's nothing stopping you from doing that. You then have peers that service requests in their own right.
It's tricky trying to discuss implementation issues without knowing the architecture, or what you're trying to achieve.
strlen is 5
You should do
sendto(sockfd, ss, sizeof(ss), ...
If you install Wireshark, you can see what's being sent and received.
You should do
sendto(sockfd, ss, sizeof(ss), ...
If you install Wireshark, you can see what's being sent and received.
Why are you deleting your posts? You're receiving the benefit of quite expensive knowledge for free. The least you could do is leave your posts for the benefit of the community.
No posts==no more help.
No posts==no more help.
Pages: 12