cjhanks / pyudt Goto Github PK

The UDT::sendfile( ... ) and UDT::recvfile( ... ) take in std::fstream objects which must be seekable.

There is no direct translation from a FILE* --> std::fstream solution and therefore no way to convert Python files into C++ files.

The UDT library executes its pthread wait conditions internally for the file operations, which prevents lockups.

Some solution to either mimic the function or translate the types needs to be created for PyUDT's sendfile/recvfile.

Merry Christmas!

from udt4 import pyudt
s = pyudt.UdtSocket()
s.fileno()

This fails with:

AttributeError: 'UDTSOCKET' object has no attribute 'UDTSOCKET'

Maybe it has to return an integer ?!

The UDT submodule is a non-working version from the CVS branch. This needs resolving / patching.

Hello,

pyudt4_send

When padding is used, it sends the buffer and then sends the remaining needed bytes needed to reach the padding. The problem is that we have no idea how much of the buffer was actually sent ( Unlike sending with no padding ). It could send only part of the buffer and then it will follow by sending the remaining padding bytes (pref_len - buf_len) and this will break integrity. Moreover the function only returns the number of bytes added to reach the padding or more precisely the number of bytes added to reach the padding that was actually sent.

I hesitated on a patch but don't know the best approach, everything feels weird.

One approach would be to make a loop to be sure that the buffer is totally sent before adding padding and return the actual total size of what was sent ( len_buf + rc ) but if it doesn't equal to the padding size that was submitted, what does the user do ? he will be obliged to loop and send padding bytes ( '\0' ) until completion. And sending padding bytes on this end feel weird to me.

A workaround for this would be to make a loop, as before to make sure that the buffer is totally sent and to make one to make sure that the padding bytes are totally sent. But then sending with padding will always return the padding length that was supplied because we made sure everything was sent before returning. And that feels strange because it will never need another call ( well if it doesn't raise an error ) on python side whereas sending without padding always will need a loop.

Of course the last approach would be to make a loop too when sending without padding and then the python send() will always need only one call to send data. This may be the best approach I see but maybe there are some I didn't think of.

What do you think ?

This needs re-working, when pip installed on one system it failed with the TCP sockets.

The accept method in python socket module returns address containing both the ip and port number of the peer, but in pyudt only the the ip is given.

Also, according to udt documentation:

If there is no connections in the queue when accept is called, a blocking socket will wait until a new connection is set up, whereas a non-blocking socket will return immediately with an error.

Maybe if after the call in c++ a compare to EASYNCRCV can achieve the same behaviour ?

I've build pyudt4 for MAC El Capitan and it succeeded. When I do import udt4 I don't get any error. But when I try to connect a udt server using udt4 I'm getting the below error.

>>> import udt4
>>> udt4.socket(socket.AF_INET, socket.SOCK_STREAM, 0)
<UDTSOCKET object at 0x101b51f30>
>>> uds = udt4.socket(socket.AF_INET, socket.SOCK_STREAM, 0)
>>> udt4.connect(uds, 'my_host_ip', 5002)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
udt4.UDTException: (1003, 'Connection setup failure: unable to create/configure UDP socket: No buffer space available.')

I have tried to increase UDT_RCVBUF and UDT_SNDBUF as specified at here eminence/udt-rs#2

PS: I don't have any issues when using the udt4 library on Windows 10

When using something like server and client when you don't uncomment the accept and recvmsg part in the server, every wait allocs a new UDTSOCKET object, which has a workaround, but you are bound to process the socket or the system will run out of memory. This does not occur when using UDT's wait, because it fills the set with primitives.

Cheers,
Martin