RejectedSoftware Forums

Sign up

Can vibe.d's programming model work for a singular connection?

avatar
Kelet
Posted Fri, 12 Jun 2015 13:24:17 GMT
Reply

Hello,

I'm attempting to use the fiber-based blocking programming model that vibe.d provides, but I'm having trouble adapting it to my situation.

I have a singular TCPConnection with a remote server. I send data to the remote server and then wait for some response data on that same connection. The response data typically takes a few seconds to arrive. Sending and receiving data are done in separate fibers. Unfortunately, this means that if I attempt to send data while waiting to receive data, my program generates an exception as the sending fiber cannot acquire the TCPConnection's context (it is in use by the receiving fiber).

I cannot use anything like a ConnectionPool as I'm confined to a singular connection.

Any suggestions?

Re: Can vibe.d's programming model work for a singular connection?

avatar
Charles
Posted Fri, 12 Jun 2015 16:57:08 GMT in reply to Kelet
Reply

On Fri, 12 Jun 2015 13:24:17 GMT, Kelet wrote:

I cannot use anything like a ConnectionPool as I'm confined to a singular connection.

I'm curious as to why that's a requirement...

What you're trying to do is put a hose in a pipe, fill it up with water from one side. At the same time, you already have a hose filling it up with water on the other side. If you could actually manage this you'd never be able to figure out where the water came from. Water is water.

In order to get around this, you need to do one of two things:

  1. Clear the pipe prior to sending stuff the other direction.
  2. Get a new pipe dedicated to moving in the other direction.

Option 2 isn't an option for you based on what you've said. Clearly this issue isn't specific to Vibe.d, but to the problem itself.

That means you need to have one connection and switch it. Fortunately, you could keep your current model with multiple fibers, and create a manager to figure out if you have data to send or data to receive, and then hand-off the connection appropriately.

Re: Can vibe.d's programming model work for a singular connection?

avatar
Kelet
Posted Fri, 12 Jun 2015 17:37:26 GMT in reply to Charles
Reply

On Fri, 12 Jun 2015 16:57:08 GMT, Charles wrote:

On Fri, 12 Jun 2015 13:24:17 GMT, Kelet wrote:

I cannot use anything like a ConnectionPool as I'm confined to a singular connection.

I'm curious as to why that's a requirement...

What you're trying to do is put a hose in a pipe, fill it up with water from one side. At the same time, you already have a hose filling it up with water on the other side. If you could actually manage this you'd never be able to figure out where the water came from. Water is water.

In order to get around this, you need to do one of two things:

  1. Clear the pipe prior to sending stuff the other direction.
  2. Get a new pipe dedicated to moving in the other direction.

Option 2 isn't an option for you based on what you've said. Clearly this issue isn't specific to Vibe.d, but to the problem itself.

That means you need to have one connection and switch it. Fortunately, you could keep your current model with multiple fibers, and create a manager to figure out if you have data to send or data to receive, and then hand-off the connection appropriately.

Hi Charles,

Thanks for the response.

I'm working with a remote host that I don't have any control over. If I have an active connection, and I connect again, the original connection is terminated. That's just how the remote host works.

As to your pipe analogy: I'm not very keen on network communications but are sockets not typically full duplex?

Thanks,
Kelet

Re: Can vibe.d's programming model work for a singular connection?

avatar
Etienne Cimon
Posted Fri, 12 Jun 2015 20:13:52 GMT in reply to Kelet
Reply

On Fri, 12 Jun 2015 17:37:26 GMT, Kelet wrote:

As to your pipe analogy: I'm not very keen on network communications but are sockets not typically full duplex?

Thanks,
Kelet

Hi Kelet,

The interface for the TCPConnection includes both read(ubyte[]) and write(ubyte[]). The read and write are both separate, which means you can read from one fiber and write from another. You're probably forgetting to send a trace if you got an error.

This being said, I don't recommend you read and write from separate fibers. You should typically align all your TCP operations within a single fiber.