bantherewind / cinder-asio Goto Github PK

The provided UdpServer API doesn't make any affordance to enable address reuse, which can be a challenge for some protocols that expect to respond to UDP client messages on the sending port.

Address reuse must be set after the socket has been opened and before bind, so it would appear as though this would require a change to UdpServer::accept(). Initially I thought I'd add a bool arg with a default value, but that won't work given the base class declaration. What would be the right way to do this, a setter/getting to set the state before accept? If so, I can submit a PR with the change, the majority of which is below.

void UdpServer::accept( uint16_t port )
{
    UdpSessionRef session = UdpSession::create( mIoService );

    boost::system::error_code errCode;
    session->mSocket->open( boost::asio::ip::udp::v4(), errCode );

    if ( errCode ) {
        if ( mErrorEventHandler != nullptr ) {
            mErrorEventHandler( errCode.message(), 0 );
        }
    } else {
        if ( reuseAddress ) {
            boost::asio::socket_base::reuse_address addressOption( true );
            session->mSocket->set_option( addressOption, errCode );
            if ( errCode ) {
                mErrorEventHandler( errCode.message(), 0 );
                return;
            }
        }

        session->mSocket->bind( udp::endpoint( udp::v4(), port ), errCode );
        if ( errCode ) {
            if ( mErrorEventHandler != nullptr ) {
                mErrorEventHandler( errCode.message(), 0 );
            }
        } else {
            if ( mAcceptEventHandler != nullptr ) {
                mAcceptEventHandler( session );
            }
        }
    }
}

The creation of a new TcpAcceptorRef crashes if the port matches the previous port.

Simplest test:

mServer = TcpServer::create( io_service() );
mServer->accept( 2000 );
mServer->accept( 3030 ); // works
mServer->accept( 3030 ); // crashes

Hey, after doing a quick survey I noticed that there are some places where ci::Buffers are being passed by value (like in the various onRead() methods). Where this was almost free before, it will now cause the Buffer to be copied, so once this goes through you'll probably want to either update those to be BufferRefs or pass by const&.

At present, the read event only handler is only provided the data buffer, SessionInterface.h#L87:

    std::function<void( ci::Buffer )>   mReadEventHandler;

it does not include any reference to the sender, which can make responses a challenge.

UdpSession::read uses async_receive:

void UdpSession::read( size_t bufferSize )
{
    mBufferSize = bufferSize;
    mSocket->async_receive( mResponse.prepare( bufferSize ), 
        boost::bind( &UdpSession::onRead, shared_from_this(), 
            boost::asio::placeholders::error, 
            boost::asio::placeholders::bytes_transferred ) );
}

but if async_receive_from were used, it would accept and populate an boost::asio::ip::udp::endpoint:

void UdpSession::read( size_t bufferSize )
{
    mBufferSize = bufferSize;
    mSocket->async_receive_from( mResponse.prepare( bufferSize ),
        mRemoteEndpoint,
        boost::bind( &UdpSession::onRead, shared_from_this(), 
            boost::asio::placeholders::error, 
            boost::asio::placeholders::bytes_transferred ) );
}

which could later be provided (via onRead) to a UDP specific read event handler that had the additional argument? Locally I've added an addition event handler in my UdpSession and have copied the content from SessionInterface::onRead() but I'd hope there were a better way…

The TCP side doesn't have a similar need since it is connection based right?

I'm not sure if this is more a bug in Cinder or in the Asio block.

libboost_regex binaries are no longer included in Cinder (the latest). Somehow, the Cinder-Asio block is triggering VS2013 to look for those binaries when the Asio source files are included.

Is it possible to modify the Cinder-Asio files to not request boost::regex binaries? Or do you have those build against 1.55 and vs2013 already?

Hey there, love the block! Thanks! Was working beautifully with Cinder's android_linux branch until this commit where they upgraded to Asio 1.11.0. At least the implementation of asio::strand changes. Would love to see this up and running with the linux branch again as I love the block and am excited about all the recent Cinder linux dev!

Maybe I'm doing something wrong... but I'm getting a lot of strange behavior with UDP
(I'm running on Linux, but it shouldn't matter I don't think...)

I've noticed this behavior in an app of mine, but I'm seeing it in the UDP Client/Server Sample as well.

Example that you can replicate:
You launch the client and server with the correct IP on the client side (in the example it's loopback), the system connects and you can send messages. But then if you put in an invalid IP and click "Write" messages still get send to the old IP and they'll show up on the server!

In my app it will sometimes stays connected, sometimes it won't. I also get strange behavior where it seems to say it's connected when you input an invalid IP

I had an issue when leaving the app (destrying TcpServer) that it received an error message and could not handle it beacuse the objects in the server where gone.

Just added mErrorEventHandler = nullptr; to de destructor.

TcpServer::~TcpServer()
{
mAcceptEventHandler = nullptr;
mCancelEventHandler = nullptr;
mErrorEventHandler = nullptr;
cancel();
}

Good day!
Quick description:
I've used Cinder-Asio in my project and in some point get strange results - UDP packets, that my program received, were lost or corrupted. As far it was ArtNet packets, that has "sequence number" field, I can trace if packets lost.
I've made some modification in Cinder-Asio sample "MultiUdpServer" to receive and check ArtNet packets, and it works fine. After that I've changed buffer size (as I've done before in my program): instead of calls to seesion->read() in callbacks i've called session->read(MAX_BUFFER_SIZE). And that's point. If MAX_BUFFER_SIZE is 530 bytes or less - everything is works fine, if 540 or greater - packets are lost or corrupted (didn't test values between 530 and 540).
Is it ci::Buffer problem?
Any ideas?

We're not sure why, but we can't send a packet over UDP of 9400 bytes on Mac OS X, though it works fine on Windows. We are getting an error callback with error string "Message too long". AFAIK we should be able to send up to 65507, any idea why we can't?

You can test by modifying line 207 of UdpClientApp.cpp(dev branch) to be:

ci::Buffer buffer( 9400 );
mSession->write( buffer );

Maybe we are missing an option or setting?

Hi,
I have this error on windows (actually I'm mac user)
1>LINK : fatal error LNK1104: cannot open file 'cinder-v140_d.lib'
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

I'm trying to compile using Cinder 0.9.0
Thanks for the help

Hi, I'm not sure if this block is still being maintained or not but I just wanted to point out a very strange behavior I faced when making a simple messaging system with a libcinder app as a TCP Client and a node.js TCP server on LAN:

Modifying the TcpClient sample, I removed the mSession->close() line from the end of the onRead method because unlike the sample I wanted to keep my connection alive with the server for many hours. I replaced that line with a mSession->read() because I wanted the client to keep listening of course and I needed it there because I didn't necessarily write back to server after I read a buffer so I couldn't just keep the mSession->read() at the end of the onWrite() method. I still kept that though so that the client could keep listening after every time it wrote a message to the sever. But as my code evolved I noticed that sometimes the client read an empty buffer in onRead() whereas it should have read a message. I played around with the code and realized that removing mSession->read() from onWrite mitigated the bug! Should that be the case? Why would having 2 read() calls on the session conflict each other? Is that an expected result or was I doing something wrong? On the whole, why do we need to say mSession->read() every time and can't we have a client that is constantly listening/reading?

No longer compiles due to this error, tested on Cinder 0.9.1 on OSX. I think it would be fixed by this pull request.

It looks like two things need to be done to support glNext:

1. Migrate from Boost ASIO to standalone ASIO
2. Update the samples

PR #10 updates the UDP samples, but requires an older rev like cinder/Cinder@bea6a85 before standalone ASIO was integrated.

I'm using Cinder glNext. Maybe I have mixed boost version.
Any hints?