I have some issues getting information about the acknowledgement of a TCP connection.
I've implemented a basic TCP Socket Server (socket(), listen(), bind(), accept(), send()) using Windows sockets. The communication works fine but now I want to retrieve and observe the incoming acknowledgements of the TCP packet.
Does anyone knows how I can get this information programmatically?
If your application needs to know when the data is received, or even in the case of failure, how much was received, you need an application-level acknowledgement.
The TCP ACK does not belong to the Application layer, it is purely layer-4 book-keeping information. If layer7 needs an ACK you need to add one at layer 7.
Related, the same goes for keep-alives: Asyncsockets and "silent" disconnections
Related
i wrote a multithreaded UDP server after the following scheme:
Scheme:
1 Receiver Thread
(Multiple Worker Threads, each has an own Socket, not bindend ,just created Ipv4, UDP,Datagram)
Message gets pushed to 1 worker which then proceed's it and then sends an answere with its own socket.
Problem:
This works perfectly on all my own test programs but for some odd reason it doesnt work with an old software for what i am emulating the server. The software uses async Wsa (overlapped), but i still doesn't get why it doesnt work.
Confusion:
It works if I use the same socket for sending as i used for receiving the data on the serverside. I dont get why, udp is a connectionless protocol so how can it detect a different socket?
Confusion: It works if I use the same socket for sending as i used for
receiving the data on the serverside. I dont get why, udp is a
connectionless protocol so how can it detect a different socket?
If you look in the UDP headers of the packets you are sending you will notice that they contain a "UDP Source Port" field. That field can be examined by the receiver of the packet (via recvfrom()) to find out which UDP port the sending UDP socket used on the sending machine (note that this is different from the "UDP Destination Port" field that determines which port the packet should be delivered to on the receiving machine). It's possible that in your case, the program you are communicating with is looking at that field and adjusting its behavior based on that field's value.
If you're wondering what that field will be set to if you never called bind() on the sending UDP socket, the answer is that the OS will choose an available UDP port number to send from (essentially an implicit bind()).
I have written a client using plain sockets in C to connect to a remote machine to maintain a persistent connection so as to receive push messages. Everything works great. To make it persistent, I have set Keepalive and waiting on recv() function in a loop.
The problem is, when the network interface goes down, the recv() does not return. As I understand from socket documentation that the peer has to disconnect for recv() to return. Network Interface going down is not the same as peer disconnecting.
The need here is that if the network interface goes down, I need to schedule a reconnect so that the channel gets established.
Any thoughts on this please?
Use whatever mechanism you wish to force the receive operation to timeout. Depending on the specifics of your use case, you may wish to disconnect if a timeout occurs or you may wish to send something to check the status of the connection.
Whatever protocol you are using on top of TCP should be documented and the documentation should specify how disconnects are detected. You must send to detect a connection loss, so every protocol designed to operate on top of TCP should be designed with this in mind.
I have 2 UDP sockets (SOCKET), one for sending and one for receiving on a Windows machine. They both work well, but the trouble is that a program that is receiving messages from my send socket replies to the same port which sent the message.
I know that if I don't bind the send socket, using sendto will pick an ephemeral port to send on.
I'd like to know if it is possible to any of the following, and if so, what is the recommended way to do it:
Bind both the send and receive sockets to a chosen port so that when the external program sends a message back it can be received.
Update the port to which the receive socket is bound in such a way as to receive on the port from which I last sent a message (not sure if this would create a race condition).
Some other correct method.
So far I have tried:
Not binding the send socket (it sends from some open port to the destination port). I can successfully receive messages on that port for as long as it doesn't change, but eventually it does change.
Binding both the send and receive sockets to a desired port. This creates the desired behaviour when I watch the packets using a sniffer, but the receive socket never receives the messages even though I see them being transmitted to the correct port and IP.
Packets are being received from more than one outside entity, and not guaranteed to be in any particular order.
Thank you in advance!
Looks like you are trying to use threads to separate sending and receiving data. I would question this approach, since UDP is so easy to handle in one thread. Nevertheless, you can just use the same socket from both threads if you want (see related question: Are parallel calls to send/recv on the same socket valid?). Just bind(2) it and, optionally, connect(2) it.
I know that SOCKS 5 supports UDP and I have been over the structure of the packets that are sent/received in negotiating with a SOCKS proxy.
The one thing I am not clear on is the procedure for setting up to register with a proxy to send/receive UDP packets.
Specifically, my biggest question is, "Is the connection to the SOCKS proxy that is used to negotiate a UDP associate relationship still made with TCP/IP?". In other words, "Do you end up using a TCP/IP socket to receive UDP packets routed through a SOCKS proxy?"
I would imagine that, if you used a TCP/IP connection to establish a pathway for UDP communication, you'd kind of be missing the whole point of establishing UDP communications. However, on the other hand, if the negotiation were made using UDP (and resulted in a UDP socket), then how would the relationship be terminated when your application is shutting down and no longer needs the proxy to "remember" you?
I have been all over the net looking for an example...but can't find anything. Any help (especially an example) would be appreciated.
https://www.rfc-editor.org/rfc/rfc1928
"A UDP-based client MUST send its datagrams to the UDP relay server at
the UDP port indicated by BND.PORT in the reply to the UDP ASSOCIATE
request"
but
"UDP association terminates when the TCP connection that the UDP
ASSOCIATE request arrived on terminates."
I actually tried using it once, but failed, because many "socks5" proxy
implementations don't actually support the complete protocol.
So I'd suggest to set up a working test case first (find an app which
would support socks5 udp proxy, and a proxy where it would actually work).
Then any network sniffer would tell you how it really works (if it does).
I have to develop a software to send same packets to multiple destination.
But i must not use multicast scheme.!!!! ( because my boss is a stupid man )
so, any way, the problem is that:
i have same packets and multiple IP address ( clients) and i can not use multicast
how can i do that in the best way?
i must use c++ as a language and Linux as a platform.
so please help me
Thanx
If your boss said you can't use multicast, maybe he/she has his/her reason. I guess broadcasting is out of the game too?
If these are the requisites, your only chance is to establish a TCP connection with every remote host you want to send packet to.
EDIT
UDP, conversely, would not provide much benefit over multicasting if your application will run over a LAN you are in charge for configuration of, that's the reason I specified TCP.
Maybe you have to describe your scenario a little better.
This could be done with either TCP or UDP depending on your reliability requirements. Can you tolerate lost or reordered packets? Are you prepared to handle timeouts and retransmission? If both answers are "yes", pick UDP. Otherwise stay with TCP. Then:
TCP case. Instead of single multicast UDP socket you would have a number of TCP sockets, one per destination. You will have to figure out the best scheme for connection establishment. Regular listening and accepting connecting clients works as usual. Then you just iterate over connected sockets and send your data to each one.
UDP case. This could be done with single UDP socket on the server side. If you know the IPs and ports of the clients (data receivers) use sendto(2) on the same data for each address/port. The clients would have to be recv(2)-ing at that time. If you don't know your clients upfront you'd need to devise a scheme for clients to request the data, or just register with the server. That's where recvfrom(2) is usefull - it gives you the address of the client.
You have restricted yourself by saying no to multicast. I guess sending packets to multiple clients is just a part of your requirement and unless you throw more light, it will be difficult to provide a complete solution.
Are you expecting two way communication between the client and the server ? in that case choosing multicast may prove complex. please clarify
You have to iterate through the clients and send packets one after another. You may want to persist the sessions if you are expecting response from the clients back.
Choice of UDP or TCP again depends on the nature of data being sent. with UDP you would need to handle out of sequence packets and also need to implement re-transmission.
You'll have to create a TCP Listerner on your server running at a particular port listening for incoming Tcp Client connections (Sockets).
Every time a client connects, you'll have to cache it in some kind of datastructre like a Name value pair (name being a unique name for the client amd value being the Network Stream of that client obtained as a result of the TCP socket).
Then when you are finally ready to transmit the data you could either iterate through this collection of name value pair connections and send them data as byte array one by one to each client or spawm off one thread per connected client and have it send the data concurrently.
TCP is a bulky protocol (due to its connection-oriented nature) and transmission of large data (like videos/images) can be quite slow.
UDP is definitely the choice for streaming large data packets but you'll have to trade-off with the delivery gurantee.