> Ooo, I can explain this one for you:
>
>    The difference between C++ and C# is... they bare absolutely no
> resemblance to each other whatsoever!

Bah! - I think if I change some "." to "::", then save my code with .cpp 
extension, and another copy with .hpp (after deleting out any actual 
implementation of methods) I should be good to go :-)

Post a reply to this message

>>> (Seriously. HTTP provides *nothing* which is useful for transferring
>>> transient data. It's just pointless overhead. What the hell is *wrong*
>>> with the world? *Why* must *everything* be kludged to work over HTTP
>>> these days? Sheesh...)
>>>
>>
>> There are two reasons for this:
>> - Everybody and their grandmother knows how to handle HTTP. You don't
>> need to rewrite a custom interface to handle AndrewTP over port 31337
>> when you want to interface with the application. (Just dealing with the
>> XML parser is enough headaches already!)
>
> But this is *still* using XML - it's just that it's sending it on top of
> HTTP rather than over a raw TCP socket.

XML is a document formatting language.  Not a transfer protocol.  XML 
does not do error handling, retransmits, keepalives, etc...  If you use 
raw TCP sockets, you need to reinvent all those wheels.

>
>> - Firewalls
>
> This is not a valid reason.
>

Yes it is.

I'm not talkinf about hiding your application traffic inside of http 
octet streams to bypass the security nazis.

In an entreprise setting. you need to do application layer parsing of 
your traffic to ensure that, amongst other things, PII does not excape, 
so using HTTP means that a third party firewall will be able to do deep 
packet inspection out of the box.

Also, HTTP is very easy to proxify, so your application will work in 
most entreprise settings, without having to resort to Socks, or other 
forms of tunnels.

>> Then program a keepalive message at the application level.
>
> Right, so now I have to have a second thread sitting in the background
> with a timer, and I have to remember to reset that timer every time a
> command is sent, and then when the timer runs down, I send a null
> command and reset the timer... Surely all this boilerplate code should
> be in the framework?
>
> Seriously, when I used plain TCP, I didn't need to do this. The helpful
> framework is forcing me to do *more* work!
>
> (Well, technically it's not the framework's fault that Mono implements
> it wrong, but anyway...)
>
>> How does your client know the difference between the server processing
>> the request and the server having exploded in a firey ball of ones and
>> zeroes?
>
> No, this is the *server* not waiting for the *client*.
>

Well, it works both ways.  If your client got abducted by aliens (or 
more likely, bluescreened)  How long do you sit there wasting resources?

What if I just decided to start 65536 sessions on your server and let 
them idle?  Can you spell "Denial of service"?

You may not need this robustness in your isolated test bed environment, 
but the makers of the WCF framework can't (or shouldn't) assume that no 
one will ever release one of these apps into the wild.

>> Client/server apps are the same. If you want the communication channel
>> to remain open, you should program a keepalive
>
> This shouldn't be necessary. (And when it was plain TCP, it *wasn't*
> necessary, because TCP already implements this for you.)
>

As I mentioned in my previous message, there should be no relationship 
between the TCP connection and the application session.  Your 
application, over the course of a single user session, may need to 
create and teardown multiple TCP sessions with the same server.  Or at 
least, this would be the smart way of doing it.  You shouldn't have to 
rely on TCP's limited error-handling to survive a network glitch.

>> and ideally an
>> erro-recovery mechanism where it will try to reconnect in case the
>> keepalive gets eaten by goblins.
>
> It appears to be impossible to tell under WCF when the connection has
> been broken.
>

In that case, the framework is rather flimsy.

>>> OK, so under Mono it appears to be _impossible_ to stop the server
>>> disconnecting.
>>
>> At the risk of repeating myself... program an application-level
>> keepalive.
>
> The solution I eventually came up with was to connect, send one command,
> and then immediately disconnect. So now the program makes a new
> connection for every individual command. It's inefficient, but what else
> can I do?

Unless you plan on sending multiple commands in rapid fire, that's how 
it should be.  Yes, you sent 6 more TCP packets per "command", but your 
app is now much more tolerant of network glitches and doesn't waste 
resources on either end of the communication channel waiting for a 
client or server that is no longer there.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

On 11/11/2013 10:56 AM, scott wrote:
>> Ooo, I can explain this one for you:
>>
>> The difference between C++ and C# is... they bare absolutely no
>> resemblance to each other whatsoever!
>
> Bah! - I think if I change some "." to "::", then save my code with .cpp
> extension, and another copy with .hpp (after deleting out any actual
> implementation of methods) I should be good to go :-)

You might also need to rename all your "interfaces" to pure virtual 
classes. Oh, and C++ has multiple inheritance. And by default C++ has 
value semantics not reference semantics. Oh, and if you try to return a 
local variable as the result of a function, your code may segfault. Oh, 
and...

Post a reply to this message

>>> - Everybody and their grandmother knows how to handle HTTP. You don't
>>> need to rewrite a custom interface to handle AndrewTP over port 31337
>>> when you want to interface with the application. (Just dealing with the
>>> XML parser is enough headaches already!)
>>
>> But this is *still* using XML - it's just that it's sending it on top of
>> HTTP rather than over a raw TCP socket.
>
> XML is a document formatting language. Not a transfer protocol. XML does
> not do error handling, retransmits, keepalives, etc... If you use raw
> TCP sockets, you need to reinvent all those wheels.

You send an XML document explaining what method you want to call. The 
server sends back an XML document either saying it went OK, or 
describing why it didn't. Provided you standardise the XML, you don't 
particularly need anything from the transport protocol.

> In an entreprise setting. you need to do application layer parsing of
> your traffic to ensure that, amongst other things, PII does not excape,
> so using HTTP means that a third party firewall will be able to do deep
> packet inspection out of the box.

How does HTTP have any baring on this?

> Also, HTTP is very easy to proxify, so your application will work in
> most entreprise settings, without having to resort to Socks, or other
> forms of tunnels.

If you're trying to send commands and replies, the *last* thing you want 
is some proxy caching it for you...

This is the fundamental problem with HTTP. It's designed to transfer 
static documents, not ephemeral commands and replies. Sure, if you bash 
it hard enough, you can just about make it work. But that's like saying 
that you *can* use a vegetable knife as a screwdriver...

>>> How does your client know the difference between the server processing
>>> the request and the server having exploded in a firey ball of ones and
>>> zeroes?
>>
>> No, this is the *server* not waiting for the *client*.
>>
>
> Well, it works both ways. If your client got abducted by aliens (or more
> likely, bluescreened) How long do you sit there wasting resources?

Until the test runner kills the client and the server.

> What if I just decided to start 65536 sessions on your server and let
> them idle? Can you spell "Denial of service"?

There will only ever be one client.

> You may not need this robustness in your isolated test bed environment,
> but the makers of the WCF framework can't (or shouldn't) assume that no
> one will ever release one of these apps into the wild.

OK, well that's fair enough. But let *me* configure how I actually want 
the thing to work.

[In fairness, WCF *has* the capability to configure it the way I want 
it. It's just that the Mono implementation is broken - it blatantly 
ignores my configuration settings!]

> As I mentioned in my previous message, there should be no relationship
> between the TCP connection and the application session. Your
> application, over the course of a single user session, may need to
> create and teardown multiple TCP sessions with the same server. Or at
> least, this would be the smart way of doing it. You shouldn't have to
> rely on TCP's limited error-handling to survive a network glitch.

I don't see why you would ever need more than one TCP connection - 
unless you're actually trying to issue multiple commands simultaneously 
or something...

>> It appears to be impossible to tell under WCF when the connection has
>> been broken.
>
> In that case, the framework is rather flimsy.

Indeed.

>> The solution I eventually came up with was to connect, send one command,
>> and then immediately disconnect. So now the program makes a new
>> connection for every individual command. It's inefficient, but what else
>> can I do?
>
> Unless you plan on sending multiple commands in rapid fire, that's how
> it should be. Yes, you sent 6 more TCP packets per "command", but your
> app is now much more tolerant of network glitches and doesn't waste
> resources on either end of the communication channel waiting for a
> client or server that is no longer there.

6 more packets, each with a round-trip delay. A bunch more kernel-mode 
calls on both sides. And the network layer just got a bunch harder to 
debug. It works, but it's hardly an ideal solution.

(Hell, UDP would be better if that's your plan... But WCF doesn't appear 
to support that.)

Post a reply to this message

Orchid Win7 v1 <voi### [at] devnull> wrote:
> Oh, and if you try to return a 
> local variable as the result of a function, your code may segfault.

Strange, given that probably at least 80% of functions do that.

-- 
                                                          - Warp

Post a reply to this message

Am 11.11.2013 21:17, schrieb Warp:
> Orchid Win7 v1 <voi### [at] devnull> wrote:
>> Oh, and if you try to return a
>> local variable as the result of a function, your code may segfault.
>
> Strange, given that probably at least 80% of functions do that.

No, not at all. Those 80% return the /value/ of a local variable. Big 
difference.

Post a reply to this message

> You might also need to rename all your "interfaces" to pure virtual
> classes. Oh, and C++ has multiple inheritance. And by default C++ has
> value semantics not reference semantics. Oh, and if you try to return a
> local variable as the result of a function, your code may segfault. Oh,
> and...

Minor details, minor details :-)

Post a reply to this message

On 12/11/2013 08:25 AM, scott wrote:
>> You might also need to rename all your "interfaces" to pure virtual
>> classes. Oh, and C++ has multiple inheritance. And by default C++ has
>> value semantics not reference semantics. Oh, and if you try to return a
>> local variable as the result of a function, your code may segfault. Oh,
>> and...
>
> Minor details, minor details :-)


If you think the fact that your code can segfault if called with a 
specific set of inputs is "minor", then... enjoy C++! :-D

Post a reply to this message

>> Minor details, minor details :-)
>
> If you think the fact that your code can segfault if called with a
> specific set of inputs is "minor", then... enjoy C++! :-D

Oh yeh, C++ memories are coming back to me now, how you can be chasing a 
bug for hours and finally realise that it's somewhere completely 
unrelated overwriting a different variable's memory by mistake... :-O

Post a reply to this message

>> XML is a document formatting language. Not a transfer protocol. XML does
>> not do error handling, retransmits, keepalives, etc... If you use raw
>> TCP sockets, you need to reinvent all those wheels.
>
> You send an XML document explaining what method you want to call. The
> server sends back an XML document either saying it went OK, or
> describing why it didn't. Provided you standardise the XML, you don't
> particularly need anything from the transport protocol.

How would you implement splitting the payload across multiple packets, 
with a direct socket connection?  How would your server know the 
difference between a malformed XML document with missing closing tags 
and a missing packet?

How do you tell your server (or client) that there should be more data 
coming?

How do you handle errors?

The answer is to reinvent XML wheels that already exist in HTTP.

>
>> In an entreprise setting. you need to do application layer parsing of
>> your traffic to ensure that, amongst other things, PII does not excape,
>> so using HTTP means that a third party firewall will be able to do deep
>> packet inspection out of the box.
>
> How does HTTP have any baring on this?
>

Everyone knows how HTTP is defined, so it's easier to find the relevant 
data in an HTTP stream, than in a proprietary protocol.

>> Also, HTTP is very easy to proxify, so your application will work in
>> most entreprise settings, without having to resort to Socks, or other
>> forms of tunnels.
>
> If you're trying to send commands and replies, the *last* thing you want
> is some proxy caching it for you...
>

I'm not talking about caching, I'm talking about relaying.  Most proxies 
are indeed caching proxies, but their priamry function is to relay 
traffic from one network to another network and keeping both networks 
isolated.

> This is the fundamental problem with HTTP. It's designed to transfer
> static documents, not ephemeral commands and replies. Sure, if you bash
> it hard enough, you can just about make it work. But that's like saying
> that you *can* use a vegetable knife as a screwdriver...
>

You are correct, that there are more specialized messagin protocols out 
there (most of them proprietary), such as IBM MQ-Series or TIBCO 
Rendezvous, just to name them, that are more suited to handling 
ephemeral commands, than HTTP, but most of the civlized world has no 
problems whatsoever using HTTP (or more often HTTPS) to exchange data 
between systems and even companies.

Since the makers of WCF do not know ahead of time what you will be doing 
with their framework, they decided to pick the most widely used tranfer 
protocol to make most of their users' life less miserable.

>> You may not need this robustness in your isolated test bed environment,
>> but the makers of the WCF framework can't (or shouldn't) assume that no
>> one will ever release one of these apps into the wild.
>
> OK, well that's fair enough. But let *me* configure how I actually want
> the thing to work.
>
> [In fairness, WCF *has* the capability to configure it the way I want
> it. It's just that the Mono implementation is broken - it blatantly
> ignores my configuration settings!]
>

Well, the Mono project webpage fully acknowledges that their support for 
WCF is limited.

>> As I mentioned in my previous message, there should be no relationship
>> between the TCP connection and the application session. Your
>> application, over the course of a single user session, may need to
>> create and teardown multiple TCP sessions with the same server. Or at
>> least, this would be the smart way of doing it. You shouldn't have to
>> rely on TCP's limited error-handling to survive a network glitch.
>
> I don't see why you would ever need more than one TCP connection -
> unless you're actually trying to issue multiple commands simultaneously
> or something...
>

In your particular case, maybe, but you are using a general purpose 
framework that is built for general use.

Let's say a travel agent is discussing various possible plane/hotel 
combinations with a client.  She shouldn't "hog" a tcp socket open for 
minutes while the client makes up his mind, nor should she have to 
re-enter her credentials everytime she checks the availablity at another 
hotel, or makes the final reservation.

In the background, the application would open one session and issue a 
session ID, after having verified the user's credentials.  Then after 
that, whenever the travel agent makes a query through her reservation 
system, the client-side application would open a new TCP sessions, 
include the application ID inside the payload and send one (or more) 
commands to the server.  The server would send the reply and the TCP 
connection would then close to leave resources available for the next agent.


-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message