If you were writing a basic python TCP server and client would you need to add the SYN, SYN ACK and ACK responses yourself or is it taken care of by the socket module?
If you need to write it yourself would it be as simple as something like this?
Client:
#set up clientSocket
data = "SYN"
clientSocket.send(data.encode('utf-8'))
if((clientSocket.recv(1024)).decode('utf-8') == "SYN ACK") {
data = "ACK"
clientSocket.send(data.encode('utf-8'))
}
and the Server responding in a similar way with checking if recv is SYN and then send SYN ACK. If not what is the correct way of implementing it?
Haven't ran the above code, not bothered about the syntax being 100% correct just curious about the logic behind it
The SYN and ACK are handled by the operating system, with no direct intervention by the user. The user program is not required, nor is it able, to send the initial SYN, SYN-ACK, ACK handshake packets.
The initial SYN is sent on behalf of the client as a consequence of socket.socket.connect().
The initial SYN-ACK is sent on behalf of the server as a consequence of socket.socket.listen().
Related
I am developing something like TCP Server in Python using scapy.
A typical TCP server should work like this.
First, it waits for an incoming SYN packet by calling sniff.
Second, it sends a SYNACK and waits for an ACK response in a single call, this is done with sr1 call.
Third, it waits for an incoming packet with a client request by calling sniff.
But the problem is that request packet can arrive between the sr1 and second sniff and thus get lost, because sniff does not capture packets that arrived before it is called.
(I can see with Wireshark that a packet is arriving).
How can I send SYNACK and receive both ACK and a request in one call, 'atomically'?
(In a typical TCP connection, the client will resend the packet with the request after some timeout, but according to the conditions of my task there is no re-sending of packets, packets cannot be lost).
You can create a scapy socket and call sr1 or sniff on it. For instance
from scapy.config import conf
sock = conf.L3socket()
sock.sr1(....)
sock.sniff(...)
Because it is the same socket, you won't be losing any packets
I have 2 servers and a client. There is 2 way communication between the server and the client. Would I need multiple sockets on the client to communicate with the servers? I used only one socket and a few of the packets from the servers are missing. How many sockets would I need to communicate with the server?
With UDP you almost always only need a single socket; you can call sendto() and recvfrom() on it to send and receive UDP packets from anywhere.
As for missing UDP packets, that is a fact of life with UDP; UDP packets can and sometimes will get dropped at any step of the path from sender and receiver. You'll need to design your app to tolerate that, or alternatively come up with a mechanism by which the receiver can detect that a packet was lost and request a resend (or otherwise somehow handle that situations).
I have a client written using python-twisted (http://pastebin.com/X7UYYLWJ) which sends a UDP packet to a UDP Server written in C using libuv. When the client sends a packet to the server, it is successfully received by the server and it sends a response back to the python client. But the client not receiving any response, what could be the reason ?
Unfortunately for you, there are many possibilities.
Your code uses connect to set up a "connected UDP" socket. Connected UDP sockets filter the packets they receive. If packets are received from any address other than the one to which the socket is connected, they are dropped. It may be that the server sends its responses from a different address than you've connected to (perhaps it uses another port or perhaps it is multi-homed and uses a different IP).
Another possibility is that a NAT device is blocking the return packets. UDP NAT hole punching has come a long way but it's still not perfect. It could be that the server's response arrives at the NAT device and gets discarded or misrouted.
Related to this is the possibility that an intentionally configured firewall is blocking the return packets.
Another possibility is that the packets are simply lost. UDP is not a reliable protocol. A congested router, faulty networking gear, or various other esoteric (often transient) concerns might be resulting in the packet getting dropped at some point, instead of forwarded to the next hop.
Your first step in debugging this should be to make your application as permissive as possible. Get rid of the use of connected UDP so that all packets that make it to your process get delivered to your application code.
If that doesn't help, use tcpdump or wireshark or a similar tool to determine if the packets make it to your computer at all. If they do but your application isn't seeing them, look for a local firewall configuration that might reject them.
If they're not making it to your computer, see if they make it to your router. Use whatever diagnostic tools are available (along the lines of tcpdump) on your router to see whether packets make it that far or not. Or if there are no such tools, remove the router from the equation. If you see packets making it to your router but no further, look for firewall or NAT configuration issues there.
If packets don't make it as far as your router, move to the next hop you have access to. This is where things might get difficult since you may not have access to the next hop or the next hop might be the server (with many intervening hops - which you have to just hope are all working).
Does the server actually generate a reply? What addressing information is on that reply? Does it match the client's expectations? Does it get dropped at the server's outgoing interface because of congestion or a firewall?
Hopefully you'll discover something interesting at one of these steps and be able to fix the problem.
I had a similar problem. The problem was windows firewall. In firewall allowed programs settings, allowing the communication for pythonw/python did solve the problem. My python program was:
from socket import *
import time
address = ( '192.168.1.104', 42) #Defind who you are talking to (must match arduino IP and port)
client_socket = socket(AF_INET, SOCK_DGRAM) #Set Up the Socket
client_socket.bind(('', 45)) # arduino sending to port 45
client_socket.settimeout(1) #only wait 1 second for a response
data = "xyz"
client_socket.sendto(data, address)
try:
rec_data, addr = client_socket.recvfrom(2048) #Read response from arduino
print rec_data #Print the response from Arduino
except:
pass
while(1):
pass
I have a client-server "snake" game working really well with TCP connections, and I would like to try it the UDP way.
I wonder how it is supposed to be used ? I know how UDP works, how to make a simple ECHO example, but I wonder how to do the following :
For instance with TCP, every TICK (1/15 second) server sends to the client the new Snake head position.
With UDP, am I supposed to do something like this :
Client SIDE :
client = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
serverAddr = (('localhost', PORT))
while 1:
client.sendto('askForNewHead', serverAddr)
msg, addrServer = client.recvfrom(1024)
game.addPosition(msg)
Server SIDE :
server = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
server.bind((HOST, PORT))
while 1:
data, addr = server.recvfrom(1024)
server.sendto(headPosition, addr)
So here Client has to ask server to get the new head position, and then server sends the answer. I managed to make it work this way, but I can't figure out if it is a good way of doing.
Seems weird that client has to ask udp for an update while with my TCP connection, client has just to wait untill he receives a message.
There are differences between TCP and UDP but not the way you describe. Like with TCP the client can recvfrom to get messages from the server without asking each time for new data. The differences are:
With TCP the initial connect includes a packet exchange between client and server. Unless the client socket was already bound to an IP and port it will be bound to the clients IP and a free port will be allocated. Because of the handshake between client and server the server knows where to contact the client and thus can send data to the packet without getting data from the client before.
With UDP there is no initial handshake. Unless already bound, the socket will be bound to clients IP and a free port when sending the first packet to the server. Only when receiving this packet the server knows the IP and port of the client and can send data back.
Which means, that you don't need to 'askForNewHead' all the time. Instead the client has to send only a single packet to the server so that the server knows where to send all future packets.
But there are other important differences between TCP and UDP:
With UDP packets may be lost or could arrive in a different order. With TCP you have a guaranteed delivery.
With UDP there is no real connection, only an exchange of packets between two peers. With TCP you have the start and end of a connection. This is relevant for packet filters in firewalls or router, which often need to maintain the state of a connection. Because UDP has no end-of-connection the packet filters will just use a simple timeout, often as low as 30 seconds. Thus, if the client is inside a home network and waits passively for data from server, it might wait forever if the packet filter closed the state because of the timeout. To work around this data have to be transmitted in regular intervals so that the state does not time out.
One often finds the argument, that UDP is faster then TCP. This is plain wrong. But you might see latency problems if packets get lost because TCP will notice packet loss and send the packet again and also reduce wire speed to loose less packets. With UDP instead you have to deal with the packet loss and other congestion problems yourself. There are situations like real time audio, where it is ok to loose some packets but low latency is important. These are situations where UDP is good, but in most other situations TCP is better.
UDP is different to TCP, and I believe with python the client does have to ask for an update from the server.
Although it is fun to learn and use a different way of communicating over the internet, for python I would really recommend sticking with TCP.
You don't have to ask the server for a update. But since UDP is connection-less the server can send head-positions without being asked. But the client should send i'm-alive-packets to the server, but this could happen every 10 seconds or so.
I have implemented a Modbus over TCP as server software in Python. App is multithreaded and relies heavily on standard libs. I have problems managing the connection on the server side.
Meanwhile my implementation as Modbus over TCP as client works just fine.
Implementation description
The server is multithreaded, one thread manages the SOCK_STREAM socket for receiving
frames
select is used out of efficiency reasons
A semaphore is used for preventing concurrent access on socket resource while sending or receiving
Encapsulation of Modbus upper layer is done transparently through send and receive methods, it is only a matter of building a frame with the right header and payload anyway...
Another threads runs, inside it, Modbus send and receive methods are invoked.
TCP Context
TCP is up and running, bound to a port, max client set and listening.
Traces under wireshark show:
Client: SYN
My app Server: SYN, ACK
Client: ACK
On the server side a brand new socket has been created as expected and bound to the client socket.
So far, all is good.
Modbus Context
Client: Send Modbus frame, TCP flags = 0x18 which is ACK + PUSH
My app Server: Does not wait and send a single empty TCP ack frame.
Client: Waits for a modbus frame with tcp ack flag. Therefore, takes it as an error and asks to closes the connection.
Hence, my server software cannot send any actual response afterwards as the socket on the client side is being closed or is already closed.
My problem
I receive a modbus frame that the main thread need to process (server side)
Processing takes a few ms, in the meantime a TCP ACK frame is sent through my server socket, whereas I would like it not to send anything !
Do you have any idea on how to manage the ACK behavior ? I have read stuff about the naggle algorithm, but it does not seem to be in the scope of the problem here...
I'm not sure that any option of the setsockopt method would solve my problem also, but I may be mistaken.
If you have any suggestion I am very interested...
I hope I am clear enough.
It seems like a strange requirement that all TCP packets must contain a payload as this is very difficult to control unless you are integrated with the TCP stack. If it really is the case that the client crashes because the ACK has no Modbus payload, I think the only thing you can do from python is try disabling the TCP_QUICKACK socket option so that TCP waits 500ms before sending an ACK. This obviously won't work in all cases (or may not at all if it takes your code > 500ms to create a response), but I don't know of any other options using the socket API from python.
This SO answer tells you how to disable it: Disable TCP Delayed ACKs. Should be easy to figure out how to enable it from that. Note, you need to constantly re-enable it after receiving data.