[newbie] trying socket as a replacement for nc

[Chris Angelico]

Good point -- I meant send(). I keep forgetting that the libc socket
write() operation is missing in Python and only the send() call has
been made visible. In C write() and send() are effectively the same
thing (the parameters are arranged a little differently, but they
behave identically otherwise).

Mostly - send() lets you set options, write() is equivalent to send()
with no options set. But other than that, they're identical, as stated
in man 2 send.

ChrisA

 

[Jean Dubois]

Op donderdag 12 december 2013 22:23:22 UTC+1 schreef Dan Stromberg:

This is untested, but it should be something like the following:
#!/usr/bin/env python
"""
A simple echo client
"""
import socket as socket_mod
import bufsock as bufsock_mod
host = '10.128.59.63'
port = 7000
size = 10
socket = socket_mod.socket(socket.AF_INET, socket.SOCK_STREAM)
socket.connect((host,port))
bufsock = bufsock_mod.bufsock(socket)
bufsock.send('*IDN?')
data = bufsock.recv(size)
bufsock.close()
print 'Received:', data
You might look over
http://stackoverflow.com/questions/...ication-server-using-python/19918706#19918706
for a more complete example.

So this is what I did:
1. svn checkout http://stromberg.dnsalias.org/svn/bufsock/
2. cd ~/bufsock/trunk
3. I made this test-file "buftest.py" with the following contents:
#!/usr/bin/env python

"""
A simple echo client
"""
import socket as socket_mod
import bufsock as bufsock_mod
host = '10.128.59.63'
port = 7000
size = 10
socket = socket_mod.socket(socket.AF_INET, socket.SOCK_STREAM)
socket.connect((host,port))
bufsock = bufsock_mod.bufsock(socket)
bufsock.send('*IDN?')
data = bufsock.recv(size)
bufsock.close()
print 'Received:', data

4. chmod +x buftest.py
5. ./buftest.py
6. This results in the following error message:
Traceback (most recent call last):
File "./buftest.py", line 11, in <module>
socket = socket_mod.socket(socket.AF_INET, socket.SOCK_STREAM)
NameError: name 'socket' is not defined

Probably there is still something wrong, can anyone here help me further?

kind regards,
jean

 

[Ervin Hegedüs]

hello,

#!/usr/bin/env python

"""
A simple echo client
"""
import socket as socket_mod
import bufsock as bufsock_mod [...]
Traceback (most recent call last):
File "./buftest.py", line 11, in <module>
socket = socket_mod.socket(socket.AF_INET, socket.SOCK_STREAM)
NameError: name 'socket' is not defined

you should replace the socket.AF_INET to socket_mod.AF_INET, and
socket.SOCK_STREAM to socket_mod.SOCK_STREAM, if you've imported
socket modul as socket_mod. But this is just an idea...


a.

 

[88888 Dihedral]

Sockets reserve the right to split one socket.send() into multiple
socket.recv()'s on the other end of the communication, or to aggregate
multiple socket.send()'s into a single socket.recv() - pretty much any way
the relevant IP stacks and communications equipment feel like for the sake
of performance or reliability.

Just to be pedantic: _TCP_ sockets reserver that right. UDP sockets
do not, and do in fact guarantee that each message is discrete. [It
appears that the OP is undoubtedly using TCP sockets.]

I haven't done a lot of UDP, but are you pretty sure UDP can't at

least fragment large packets? What's a router or switch to do if the

Path MTU isn't large enough for an original packet?

http://www.gamedev.net/topic/343577-fragmented-udp-packets/

I'm no expert on this (mostly I do TCP, or UDP with fairly small

packets), but the packet should be reassembled at the far end. When

your application comes to receive it, it'll receive the entire UDP

packet as a whole.



UDP fragmentation has several problems. First, if any fragment is

lost, it won't be retransmitted (as TCP will), so the whole datagram

is lost. And secondly, if you stream data across the network in a

series of packets just a little too large to fit, each one will get

split in two and you'll end up with twice as many packets going out,

ergo abysmal performance. With TCP, there's the chance that the sender

and receiver can between them figure out what packet size to use (cf

path MTU discovery), but that won't happen with UDP unless the

application consciously does it. So it's something to be cautious of

in terms of performance, but if you want to send large UDP packets

because they make sense, just go ahead and do it.



Now, if you want reliability AND datagrams, it's a lot easier to add

boundaries to a TCP stream (sentinel or length prefixes) than to add

reliability to UDP...



ChrisA

It is trivial to use UDP with
forward error correction such as
the CD in 1982.

 

[Chris Angelico]

It is trivial to use UDP with
forward error correction such as
the CD in 1982.

This is another reason for moving to IPv6. With IPv4, the size of a
datagram is limited to 64KB, but with IPv6, you could carry an entire
CD's contents in a single message. You could not carry a DVD, though,
so Dihedral is quite correct to cite the CD here.

ChrisA

 

[Roy Smith]

It is trivial to use UDP with
forward error correction such as
the CD in 1982.

CD uses Reed-Solomon coding, which is great for correcting the types of
errors expected on a CD. Namely, bursts of bit errors caused by
localized failure of the optical coating, scratches, dirt, etc. It
wouldn't be hard to build something like that on top of UDP, but those
sorts of errors are not what you typically see in networks.

It's relatively rare for a bit to get corrupted in a network packet.
And, when it does, it's almost certainly caught by lower-level
mechanisms such as ethernet frame CRC. Much more likely is for a packet
to get dropped because of queue overflow, or for sequential packets to
arrive out of order due to multiple transmission paths with different
latencies. Those are the sorts of things TCP protects against.

Sure, you could implement retransmit timers and packet reordering in
user code, but it would be distinctly non-trivial and ultimately you
would end up reinventing most of TCP. Except that your implementation
would suck compared to the kernel algorithms which have been
continuously tested and fine-tuned for the past 30 years.

 

[88888 Dihedral]

CD uses Reed-Solomon coding, which is great for correcting the types of

errors expected on a CD. Namely, bursts of bit errors caused by

localized failure of the optical coating, scratches, dirt, etc. It

Don't you interleave your bytes of data
first before forming several UDP
packets to send to the receiver?

If a whole packet is lost or
timed out, then just mark missed bytes
in the missed UDP as erasures.