 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
OK, so I've got a small but fairly complicated client/server program,
using a trivial custom communications protocol that I wrote myself.
Basically I want the client program to remotely execute methods in the
server program. And, as you might suspect, it turns out there are 3rd
part libraries for doing that kind of thing automatically.
One such library is Microsoft's "WCF". (No, I have no idea what that
stands for.) The idea, according to what little documentation I can
find, is that you write a C# interface, write some code that implements
that interface, and then you can hook up a client so it can call the
interface methods just as if they were local.
Trouble is, WCF is a huge, sprawling framework with a bazillion bells
and whistles. It's almost impossible to make any sense out of the API
documentation. (For one thing, it's mostly extremely terse.) What's
really lacking is something to explain the high-level abstractions and
give you somewhere to *start*...
Oh, there *is* documentation, mind you. Both from Microsoft themselves
and on various blogs and so on. But they all say something along the
lines of "open Visual Studio, select the WCF Class Library template,
watch it generate eleventy-billion lines of XML configuration file which
isn't explained or documented anywhere on the face of the Internet".
Most horrifyingly of all, it seems that absolutely everything to do with
WCF defaults to turning method calls into XML data [which seems
reasonable enough] and then transmitting it via HTTP [which is the most
absurd thing I've ever heard of]. Almost nowhere does it tell you how to
turn off the completely unnecessary HTTP layer and just run on plain TCP
sockets.
(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...)
If you walk through the examples, it does eventually work. But the way
it works is bizarre: You've written a C# interface, which lists exactly
what methods your server exposes. And yet, what they want you to do is
enable "metadata exchange (mex)", and then run a command-line tool which
connects to the server, downloads the interface description, and
generates C# code for talking to the server.
Even though the necessary information is ALREADY sitting RIGHT THERE in
that interface you just wrote! WTF?
(I suppose if the server was written by somebody on the other side of
the planet and you don't have the source code, being able to dynamically
look up its API is nice. But for any other use-case... why this much
complexity??)
Sadly, it seems that mex cannot ever be made to operate over TCP, only
HTTP. (Christ knows why...) Also disturbing is that if you use the magic
WCF template, Visual Studio somehow "knows" if your service is running
or not, and automatically starts and stops it when you try to run
clients that use it. This makes me very, very nervous!
Well, you know what? All that stuff I just said? You can completely
ignore that bunch of nonsense. Because it turns out that all you
*actually* need to do is this:
1. Write a C# interface, with the right attributes on it.
2. Write a class in your server that implements this interface.
3. Execute THREE LINES OF CODE in your server's Main() function, telling
it what class implements the interface, and where to listen for clients.
4. Write THREE LINES OF CODE in the client, using the interface type as
a generic parameter. You get passed back a proxy object which implements
the interface - but whenever you call a method, it actually executes on
the server. Transparently. With no effort from you other than writing
THREE LINES OF CODE.
So, yeah. The client and the server both reference the same C# interface
type, and WCF automagically transports arguments and results between
client and server. Other than figuring out how to connect to each other,
there's almost no code involved. In particular, you DO NOT need a
200-line XML file with undocumented contents to make this work!
Now, if something somewhere on the Internet would have just *said* all
that, I could have saved myself many, many hours of head-banging...
Of course, this all means much less code needs to be written. But on the
other hand, I just surrendered control to an external library, so now
it's much harder to work out why things aren't working. ;-)
It seems that, by default, opening a connection creates your proxy
object, but doesn't actually *connect* to the server until you try to
call a method. Which means that if anything goes wrong, instead of
throwing an exception in the connection method, it throws an exception
in some other random place in your application, depending on where you
just happen to try to use the server for the first time. :-S
It's easy enough to fix that one. It's not documented, but there's an
Open() method which forces the connection to be opened *right now*. You
know, so I can decide whether to proceed or not based on whether the
server is *actually* listening to me or not.
Unfortunately, it seems by default, if the server is *not* listening,
the Open() method simply waits forever. This is not very helpful.
Fortunately, you can trivially specify a timeout as a parameter to the
method. So that's OK.
Now the *real* fun begins! You see, I actually want to use this stuff on
a mixture of .NET and Mono. I wrote a small test project to check that I
could get this stuff to work, but I only tried it on .NET, and only on
the local machine. When I tried to modify the *real* application to use
WCF, suddenly I ran into several problems.
The first problem is that Mono *refuses* to listen on all network
interfaces. Won't do it. You can easily to it with .NET, but Mono won't.
https://bugzilla.xamarin.com/show_bug.cgi?id=275
To sumarise: If you ask .NET to listen on "localhost", it will accept
any and all incoming network connections. If you ask Mono to listen to
"localhost", it will *only* accept connections from the local machine.
Under .NET, you can listen on "0.0.0.0" to allow connections from all
configured IP addresses (including loopback). But on Mono, this THROWS
AN EXCEPTION. (!!) Finally, you can listen on one of your machine's
configured IP addresses (assuming you can FIND one...), in which case
only connections to that address are accepted.
To sumarise the summary: Mono can listen to internal connections OR
external connections, but not both at the same time [which is the
*default* action under .NET] Oh, well, unless you explicitly configure
TWO listening addresses...
So it seems an easy hack for that is to listen on whatever
Dns.GetHostName() returns. Now remote connections are allowed. (But not
local ones under Mono. But hey, the real application happens to not need
local connections...)
Next, a rather more strange issue. It seems that if you run my client
and server under .NET, everything is fine. If you run them both under
Mono, everything is fine. But if you run one under .NET and one under
Mono... the connection just hangs forever. (Or times out if you
specified a timeout value.) What the...?
OK, so that this point I'm guessing defaulting shenanigans. And it turns
out I'm right:
https://bugzilla.xamarin.com/show_bug.cgi?id=276
By default, .NET runs TCP with SSL turned on, while Mono defaults to
having SSL turned off. So presumably the client (.NET) is sitting there
waiting for some SSL handshake data, while the server (Mono) has no
intention of sending any such data - and has no idea the client is
waiting for it.
What, no feature negotiation step? :-P
The solution is pretty simple; just explicitly specify whether SSL
should be on or off. (And specify it the same way for both client and
server.) But man, do you have *any idea* how many protocol configuration
options there are?? It's a damned good thing this is the only one who's
default value differs between .NET and Mono, because otherwise I'd have
to explicitly configure every single one of them...!
Hey, wait a sec. Bug #275 is a WCF bug in Mono, and bug #276 is
*another* WCF bug in Mono. Do you suppose #277 is...
https://bugzilla.xamarin.com/show_bug.cgi?id=277
...yes, of course it is. It's *another* WCF bug in Mono. Oh goodie!
Essentially, .NET allows multiple services to listen on the same TCP
port, provided they each have a different URL. (Presumably one component
listens, then when it sees the URL it routes the connection to the
appropriate handler or something...) If you attempt to do this under
Mono, it simply throws an exception at you. Let me say that again: A
perfectly acceptable, working program on .NET summarily throws an
exception if you run it under Mono.
Oh dear. I was actually contemplating *using* that particular feature...
oh well, I guess not! (Makes that part of the URL _completely_ pointless
now though, doesn't it?)
So I deploy my new WCF code, and I hit upon *another* problem: It seems
that after a while, the server disconnects for no apparent reason.
Searching the Internet gives me nothing, until *eventually* I stumble
upon a vague reference to ReceiveTimeout.
Reading the scant documentation, it appears that if the server doesn't
hear anything for this number of seconds, it disconnects the client. The
intention seems to be that a client can't hog server resources by just
connecting and then saying nothing.
OK, a couple of things.
1. I can see how this might be bad if you were offering this service to
the entire world (or maybe just a large internal network). However, I'm
using this for 1 server with 1 client. This is an internal test
framework. It will never be exposed to the outside world. I don't *care*
about resource usage!
2. Doesn't TCP *already* send periodic heartbeat messages and close the
connection if it doesn't get a reply for a while? Why is WCF trying to
duplicate this functionality when it's already present??
Well anyway, all you have to do is go set ReceiveTimeout to some higher
value. (The documentation is inconsistent, but I believe this defaults
to 10 minutes - which is too soon, considering some of my tests take
half an hour.)
Oh, wait a sec... That works on .NET, but under Mono is has ABSOLUTELY
NO EFFECT. Wuh?! O_O
OK, so under Mono it appears to be _impossible_ to stop the server
disconnecting. So there's that. Also, while in the process of doing
this, I found that on .NET you can say AddDefaultEndpoints(), and it
does what the documentation says. However, when you run this under Mono,
it THROWS AN EXCEPTION saying the required method DOES NOT EXIST! :-O
Fortunately, it turns out I don't really need this method. It's trivial
enough to generate the default endpoint by hand. But sheesh... the
entire experience of WCF on Mono just seems to be a steaming pile of
broken. And I really don't know how to fix this disconnect issue; it's
looking like I'll have to write a pile of code to manually send
heartbeat messages to the server just to hold the connection open. (You
know - the EXACT SAME THING that the TCP layer is ALREADY DOING!!)
When you have to write MORE CODE to disable a supposed "feature" of the
framework you're using... yeah, what can you say?
On the plus side, if I ever get this stuff to work, it'll be beautiful.
I especially like the way I can make it so if the server throws an
exception, the client gets the exception (rather than just hang forever
or spit out a socket exception). I suspect this is going to make things
far more reliable...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/11/2013 08:43 PM, Orchid Win7 v1 wrote:
> Hey, wait a sec. Bug #275 is a WCF bug in Mono, and bug #276 is
> *another* WCF bug in Mono. Do you suppose #277 is...
>
> https://bugzilla.xamarin.com/show_bug.cgi?id=277
>
> ...yes, of course it is. It's *another* WCF bug in Mono. Oh goodie!
OK, so admit it: Now you want to know if #278 is WCF as well! :-D
Well no, it isn't. But I just this second realised that #274 is WCF. (It
seems a global constant is set to null under Mono.)
#273 isn't WCF though.
What I find amusing is that these bugs were reported in 2011, and most
of them are still open...
(And by "amusing" I of course mean some suitable antonym of "amusing"...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/11/13 20:43, Orchid Win7 v1 wrote:
> OK, so I've got a small but fairly complicated client/server program,
> using a trivial custom communications protocol that I wrote myself.
<snip>
> On the plus side, if I ever get this stuff to work, it'll be beautiful.
> I especially like the way I can make it so if the server throws an
> exception, the client gets the exception (rather than just hang forever
> or spit out a socket exception). I suspect this is going to make things
> far more reliable...
Thankyou Andrew for assuring me that the world still goes on (see
preceding post)
John
--
Protect the Earth
It was not given to you by your parents
You hold it in trust for your children
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/11/2013 08:47 PM, Doctor John wrote:
> Thankyou Andrew for assuring me that the world still goes on
There's no charge for this service. :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 3. Execute THREE LINES OF CODE in your server's Main() function, telling
> it what class implements the interface, and where to listen for clients.
>
> 4. Write THREE LINES OF CODE in the client, using the interface type as
> a generic parameter.
Aren't you going to share those three lines of code?
> Now the *real* fun begins! You see, I actually want to use this stuff on
> a mixture of .NET and Mono.
It wasn't too long ago you were complaining how you didn't even have a
.net runtime installed and it was a huge bloated monster and didn't
understand why anyone would want to use it - and you would have told us
all that it was obviously impossible to get any .net code working on
anything other than Windows. What a change (for the better)! :-D
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/11/2013 08:21 AM, scott wrote:
>> 3. Execute THREE LINES OF CODE in your server's Main() function, telling
>> it what class implements the interface, and where to listen for clients.
>>
>> 4. Write THREE LINES OF CODE in the client, using the interface type as
>> a generic parameter.
>
> Aren't you going to share those three lines of code?
OK, so here's what you have to do.
First, write your interface:
[ServiceContract]
public interface IDoStuff
{
[OperatioContract]
double DoTheStuff(double x, double y);
}
Next, write the server code that actually does it.
public class RealDoStuff : IDoStuff
{
...
}
Now, to serve the interface to the outside world, do this:
var host = new ServiceHost(typeof(RealDoStuff));
host.AddEndpoint(typeof(IDoStuff), "net.tcp://localhost:1664/DoStuff/");
host.Open();
Clients can now connect and run any method mentioned in IDoStuff.
Speaking of which... On the client end, do this:
var binding = new NetTcpBinding();
var factory = new ChannelFactory<IDoStuff>(binding,
"net.tcp://localhost:1664/DoStuff/");
var proxy = factory.CreateChannel();
The "proxy" object implements IDoStuff. You can call it like any other
local object. But actually, when you call it, it calls your server.
Actually, the client doesn't attempt to make a network connection until
the first time you call a method on the proxy - which is a bit annoying!
You can force it to open immediately, however:
((ICommunicationObject)proxy).Open();
A similar technique can be used to explicitly close the connection if
you want to.
Compare this to, for example,
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup>
<!-- specifies the version of WCF to use-->
<supportedRuntime version="v4.0"
sku=".NETFramework,Version=v4.5,Profile=Client" />
</startup>
<system.serviceModel>
<bindings>
<!-- Uses wsHttpBinding-->
<wsHttpBinding>
<binding name="WSHttpBinding_ICalculator" />
</wsHttpBinding>
</bindings>
<client>
<!-- specifies the endpoint to use when calling the service -->
<endpoint
address="http://localhost:8000/ServiceModelSamples/Service/CalculatorService"
binding="wsHttpBinding"
bindingConfiguration="WSHttpBinding_ICalculator"
contract="ServiceReference1.ICalculator"
name="WSHttpBinding_ICalculator">
<identity>
<userPrincipalName
value="mig### [at] redmond corpmicrosoftcom" />
</identity>
</endpoint>
</client>
</system.serviceModel>
</configuration><?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup>
<supportedRuntime version="v4.0"
sku=".NETFramework,Version=v4.5,Profile=Client" />
</startup>
<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding name="WSHttpBinding_ICalculator" />
</wsHttpBinding>
</bindings>
<client>
<endpoint
address="http://localhost:8000/ServiceModelSamples/Service/CalculatorService"
binding="wsHttpBinding"
bindingConfiguration="WSHttpBinding_ICalculator"
contract="ServiceReference1.ICalculator"
name="WSHttpBinding_ICalculator">
<identity>
<userPrincipalName
value="mig### [at] redmondcorpmicrosoftcom" />
</identity>
</endpoint>
</client>
</system.serviceModel>
</configuration>
*This* is the way Microsoft insists you have to do it.
To be fair, this has the advantage that you can change the network
configuration without recompiling your client or server code. But in my
case, since this is an internal application which only I will ever use,
this "advantage" is moot.
>> Now the *real* fun begins! You see, I actually want to use this stuff on
>> a mixture of .NET and Mono.
>
> It wasn't too long ago you were complaining how you didn't even have a
> .net runtime installed and it was a huge bloated monster and didn't
> understand why anyone would want to use it - and you would have told us
> all that it was obviously impossible to get any .net code working on
> anything other than Windows. What a change (for the better)! :-D
Well, when somebody pays you to write .NET code, you spend an hour or
two installing .NET (Actually, VS takes multiple hours to install...) It
wasn't my decision to use C#. ;-)
Having said that, C# is basically like Java, but less broken. It even
has real generics (rather than the fake generics they kludged into
Java). Hell, you can write *monads* in C#! ;-)
I'm still pretty sure that .NET was invented for the sole purpose of
vendor lock-in though. And back when I was whining about it, Mono didn't
exist. :-P
Man, the amount of bugs in the Mono WCF stuff... >_<
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> OK, so here's what you have to do.
...
That seems pretty simple, I'll file that in "useful stuff to remember" :-)
Someone at work introduced me to Arduino a few months ago (they used one
to control a test rig here), I was so impressed how simple it was to set
up and code for that I ordered one myself to tinker with at home - so
that's taking up my "spare" time at the moment. Along with decorating
the house, and playing iRacing, and keeping fit, and ... Fiddling with
C# is pretty low down the list nowadays.
> I'm still pretty sure that .NET was invented for the sole purpose of
> vendor lock-in though. And back when I was whining about it, Mono didn't
> exist. :-P
I'm sad that MS have discontinued proper 3D graphics support with C#.
You used to have the option between XNA or managed DirectX, both of
which were pretty easy to use at perfectly good enough performance
levels. Now you have to use C++ and Windows 8, which is a shame as
that's not really justification enough for me to upgrade from Windows 7
(not to mention relearning all the differences between C++ and C#).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2013-11-06 15:43, Orchid Win7 v1 a écrit :
>
> Most horrifyingly of all, it seems that absolutely everything to do with
> WCF defaults to turning method calls into XML data [which seems
> reasonable enough] and then transmitting it via HTTP [which is the most
> absurd thing I've ever heard of]. Almost nowhere does it tell you how to
> turn off the completely unnecessary HTTP layer and just run on plain TCP
> sockets.
>
> (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!)
- Firewalls
> So I deploy my new WCF code, and I hit upon *another* problem: It seems
> that after a while, the server disconnects for no apparent reason.
> Searching the Internet gives me nothing, until *eventually* I stumble
> upon a vague reference to ReceiveTimeout.
>
> Reading the scant documentation, it appears that if the server doesn't
> hear anything for this number of seconds, it disconnects the client. The
> intention seems to be that a client can't hog server resources by just
> connecting and then saying nothing.
>
> OK, a couple of things.
>
> 1. I can see how this might be bad if you were offering this service to
> the entire world (or maybe just a large internal network). However, I'm
> using this for 1 server with 1 client. This is an internal test
> framework. It will never be exposed to the outside world. I don't *care*
> about resource usage!
Then program a keepalive message at the application level.
>
> 2. Doesn't TCP *already* send periodic heartbeat messages and close the
> connection if it doesn't get a reply for a while? Why is WCF trying to
> duplicate this functionality when it's already present??
>
Not always.
TCP keepalive is an option and defaults to off.
Secondly, you may have many short-lived TCP connections part of the same
long-lived application "session" (e.g.: online shopping, or http 1.0)
> Well anyway, all you have to do is go set ReceiveTimeout to some higher
> value. (The documentation is inconsistent, but I believe this defaults
> to 10 minutes - which is too soon, considering some of my tests take
> half an hour.)
>
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?
When you get put on hold, do you prefer hearing a "your call is
important to us, please remain on the line to retain your calling
priority" reminder ever minute or so, or just hearing dead air, not
knowing if the agent hung up on you, or it looking at your file?
Client/server apps are the same. If you want the communication channel
to remain open, you should program a keepalive, and ideally an
erro-recovery mechanism where it will try to reconnect in case the
keepalive gets eaten by goblins.
> Oh, wait a sec... That works on .NET, but under Mono is has ABSOLUTELY
> NO EFFECT. Wuh?! O_O
>
> 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.
--
/*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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> (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.
> - Firewalls
This is not a valid reason.
> 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*.
> 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.)
> 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.
>> 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?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 08/11/2013 07:48 AM, scott wrote:
> (not to mention relearning all the differences between C++ and C#).
Ooo, I can explain this one for you:
The difference between C++ and C# is... they bare absolutely no
resemblance to each other whatsoever!
Part of our code is C#, and a small part is C++. We try to avoid
touching the C++ part. (I especially enjoy the way it compiles
differently under different compilers... Oh, and manually editing
Makefiles is fun too.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2013-11-08 13:38, Orchid Win7 v1 a écrit :
>>> (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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2013-11-11 14:29, Orchid Win7 v1 a écrit :
>> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> 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.
Well, if you define it like that, then it's impossible to return a local
variable. It's local.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid Win7 v1 <voi### [at] devnull> wrote:
> If you think the fact that your code can segfault if called with a
> specific set of inputs is "minor", then... enjoy C++! :-D
But then, some tasks take seconds in C++ to run, while they may take
hours with Haskell, so there's that.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/11/2013 02:06 PM, Warp wrote:
> Orchid Win7 v1<voi### [at] devnull> wrote:
>> If you think the fact that your code can segfault if called with a
>> specific set of inputs is "minor", then... enjoy C++! :-D
>
> But then, some tasks take seconds in C++ to run, while they may take
> hours with Haskell, so there's that.
Haskell isn't the only programming language which is "safe" enough that
a typical beginner won't usually cause an OS-level crash just by
accident. There are plenty of other safe languages...
It's true that a finely-crafted C++ program will probably be faster than
anything you could write in a safe language. It's also true that most
code isn't very "finely-crafted"...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/11/2013 02:01 PM, Francois Labreque wrote:
> Le 2013-11-11 14:29, Orchid Win7 v1 a écrit :
>>> 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.
TCP already handles splitting a message into packets and reassembling it
on the other side. Of the things you've mentioned, error reporting is
the *only* thing TCP doesn't already do - and that's quite easy to deal
with using XML. (HTTP lets you report a 3-digit error code. XML lets you
report an entire stack trace if you wish.)
>>> 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.
I don't see how parsing XML over HTTP is any easier than parsing XML
over raw TCP.
>>> 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.
I have no idea why you'd want to do that.
>> This is the fundamental problem with HTTP. It's designed to transfer
>> static documents, not ephemeral commands and replies.
>
> 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.
I still don't really see why you need any additional services beyond
what TCP provides. What do these proprietary protocols get you?
>> 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.
You speak as if having a TCP connection open is some terrible overhead.
If you're allocating a session ID, I would suggest that storing the
details of this session somewhere is already using *far* more resources
than a simple TCP connection...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2013-11-12 14:08, Orchid Win7 v1 a écrit :
> On 12/11/2013 02:01 PM, Francois Labreque wrote:
>> Le 2013-11-11 14:29, Orchid Win7 v1 a écrit :
>> 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.
>
> TCP already handles splitting a message into packets and reassembling it
> on the other side.
TCP only ensures that data that is split in multpiple packets will be
rassembled in the right order at the other end. It does not tell you
ahead of time how much data to expect, so you can't know in advance if
you should still be waiting for the end of that XML document, or if it
was malformed and is missing closing tags, and you should simply reject it.
> Of the things you've mentioned, error reporting is
> the *only* thing TCP doesn't already do - and that's quite easy to deal
> with using XML. (HTTP lets you report a 3-digit error code. XML lets you
> report an entire stack trace if you wish.)
>
Well, duh. XML is a document markup language. You can return a 249
page court document if you'd like, however parsing that response might
prove to be more cumbersome than necessary. There's nothing that
prevents you from sending that stack dump via HTTP either. In fact,
many applications do. Having a 200 or 503 at the start makes it easier
for the application to know if it succeeded or failed, though.
The short error codes used by SMTP, FTP, HTTP, et al. are for efficiency.
>>>> 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.
>
> I don't see how parsing XML over HTTP is any easier than parsing XML
> over raw TCP.
>
Parsing XML is parsing XML. However, getting the appliance to recognize
that the data in that tcp flow on a weird port is actually XML is
harder. It can be done in most boxes made by the big players in the
field, but it's more work.
>>>> 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.
>
> I have no idea why you'd want to do that.
>
To prevent unauthorized traffic from leaving or entering your network
(or parts of it). To mask the details of how the back-end of your
server farm is laid out. There are many valid uses for proxies, apart
from caching the Google Doodle of the day to speed up the users'
connection and cut down on bandwidth usage.
>>> This is the fundamental problem with HTTP. It's designed to transfer
>>> static documents, not ephemeral commands and replies.
>>
>> 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.
>
> I still don't really see why you need any additional services beyond
> what TCP provides. What do these proprietary protocols get you?
>
Just like SMTP is a well defined and understood way of exchanging user
messages between machines, and FTP a well defined way of exchanging
files between machines. Some people decided to create new protocols
that allowed them to send messages between applications, route them to
specific queues, define priority levels, etc... in a well defined manner
that would allow them to exchange information using a common "language".
Of course, these protocols would be overkill for a project of the size
of your testbed, but in an entreprise where the shop floor work load
management application needs to talk to the inventory system and the
employee scheduler; the inventory system needs to talk to the purchasing
application and the shipping/receiving management system; the employee
scheduler needs to talk with the payroll system; who also needs to talk
to the accounting system; who needs to interface with the external bank
system; and the inventory management can automatically place orders with
suppliers, you need something can efficiently route these messages
between all these systems.
>>> 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.
>
> You speak as if having a TCP connection open is some terrible overhead.
> If you're allocating a session ID, I would suggest that storing the
> details of this session somewhere is already using *far* more resources
> than a simple TCP connection...
Nope. Denials of service target the number of simultaneous connections
for a reason. Most servers will fork a thread for each open TCP
connection, whereas a session ID is a few bytes in a table (more,
obviously if you have other data associated with that seesion to track,
such as items in your shopping cart, for example). Managing all these
threads on a busy server can become a problem real fast.
Of course, your test bed does not need to worry about that, since you
dont expect to have more than one client and you don't expect to have
the server go back to listening mode for new clients while processing
the request of the first client.
[CSB]
About 10 years ago, we were in a "critsit" because of problems with a
customer's online banking web site. Each server in the server farm
would grind to a halt every 6 hours or so for 5-10 minutes and then pick
up where it left off. Of course, users weren't happy, and neither were
the mainframe guys in the back because of the number of unfinished
transactions that had to be rolled-back.
It turned out that Sun's HTTP server's (formlery Netscape Entreprise
Server) method of hanlding the high number of tcp connections was not to
have one thread per connection, but to put each connection state in a
table and have a pool of worker threads work the connections in turn.
Every once in a while, a "janitor" thread would spawn and freeze the
connection table while it went down the list to send an ACK to each
client, wait a few seconds and then close the connections that didn't
respond.* While it was doing this, no new connections could be
established, nor taken down gracefully. The support team keept upping
the number of allowable connections, and the number of worker threads
hoping to get rid of the problem, but only made it wors when the janitor
did start. In the end, they figured that having a very small connection
table, and having the janiotr thread constantly stopping it for a few
seconds was a much better solution than having the server come to a
complete stop for minutes at a time every few hours.
*We were on the phone with some pretty interesting "core" programmers by
the time we reached that conclusion.
[/CSB]
--
/*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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid Win7 v1 <voi### [at] devnull> wrote:
> Haskell isn't the only programming language which is "safe" enough that
> a typical beginner won't usually cause an OS-level crash just by
> accident. There are plenty of other safe languages...
I'm wondering why I should care if a beginner can make the program crash.
It's a bit like saying "power tools are dangerous, and therefore children
shouldn't be using them." Yeah, true, but why should I care? I know how
to use it.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Haskell isn't the only programming language which is "safe" enough that
>> a typical beginner won't usually cause an OS-level crash just by
>> accident. There are plenty of other safe languages...
>
> I'm wondering why I should care if a beginner can make the program crash.
>
> It's a bit like saying "power tools are dangerous, and therefore children
> shouldn't be using them." Yeah, true, but why should I care? I know how
> to use it.
OK, but given the choice between a knife that's just a sheet of metal
with sharp edges, and a knife that has a smooth handle that you can
hold, which would you prefer?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> TCP already handles splitting a message into packets and reassembling it
>> on the other side.
>
> TCP only ensures that data that is split in multpiple packets will be
> rassembled in the right order at the other end. It does not tell you
> ahead of time how much data to expect, so you can't know in advance if
> you should still be waiting for the end of that XML document, or if it
> was malformed and is missing closing tags, and you should simply reject it.
If the XML is machine-generated, it shouldn't ever be malformed. If it
is, that's a bug. (Which I suppose is something real applications have
to deal with, but it doesn't concern me overly much.)
>> Of the things you've mentioned, error reporting is
>> the *only* thing TCP doesn't already do - and that's quite easy to deal
>> with using XML. (HTTP lets you report a 3-digit error code. XML lets you
>> report an entire stack trace if you wish.)
>
> Well, duh. XML is a document markup language. You can return a 249 page
> court document if you'd like, however parsing that response might prove
> to be more cumbersome than necessary. There's nothing that prevents you
> from sending that stack dump via HTTP either.
Sure. It's just that HTTP isn't adding any real benefit here.
>> I don't see how parsing XML over HTTP is any easier than parsing XML
>> over raw TCP.
>
> Parsing XML is parsing XML. However, getting the appliance to recognize
> that the data in that tcp flow on a weird port is actually XML is
> harder. It can be done in most boxes made by the big players in the
> field, but it's more work.
How "hard" can it be to look for traffic on a particular port number?
Sheesh...
>>> 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.
>>
>> I have no idea why you'd want to do that.
>>
>
> To prevent unauthorized traffic from leaving or entering your network
> (or parts of it). To mask the details of how the back-end of your server
> farm is laid out. There are many valid uses for proxies, apart from
> caching the Google Doodle of the day to speed up the users' connection
> and cut down on bandwidth usage.
Isn't that what a firewall does?
>> I still don't really see why you need any additional services beyond
>> what TCP provides. What do these proprietary protocols get you?
>>
>
> Just like SMTP is a well defined and understood way of exchanging user
> messages between machines, and FTP a well defined way of exchanging
> files between machines. Some people decided to create new protocols that
> allowed them to send messages between applications, route them to
> specific queues, define priority levels, etc... in a well defined manner
> that would allow them to exchange information using a common "language".
OK, well if you need to relay messages between multiple machines or you
need to actually *queue* them (and presumably receive responses
asynchronously) and you start needing prioritisation and so forth...
yes, that becomes a little bit more complex.
Literally *all* I am trying to do here is have one piece of code invoke
methods in other piece of code, which happens to be on a different
machine. That's all I actually want. And everybody insists that WCF is
the only way to achieve that, so...
> Of course, these protocols would be overkill for a project of the size
> of your testbed
Perhaps that's what it comes down to.
The long and short of it is, I managed to configure WCF to *not* use
HTTP, and it works exactly the same as if it *did* use HTTP. Which, to
me, rather suggests that using HTTP is a total waste of time.
>> You speak as if having a TCP connection open is some terrible overhead.
>> If you're allocating a session ID, I would suggest that storing the
>> details of this session somewhere is already using *far* more resources
>> than a simple TCP connection...
>
> Nope. Denials of service target the number of simultaneous connections
> for a reason. Most servers will fork a thread for each open TCP
> connection, whereas a session ID is a few bytes in a table (more,
> obviously if you have other data associated with that seesion to track,
> such as items in your shopping cart, for example). Managing all these
> threads on a busy server can become a problem real fast.
Isn't that why *real* servers use thread pools or green threads or some
similar mechanism which avoids allocating an entire OS thread for every
single individual TCP connection?
It seems to me that what you're *actually* saying is that having lots of
OS threads is a lot of overhead. Well, yeah, nothing new there...
> *We were on the phone with some pretty interesting "core" programmers by
> the time we reached that conclusion.
Ah yes, the joys of garbage collection...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> To prevent unauthorized traffic from leaving or entering your network
>> (or parts of it). To mask the details of how the back-end of your server
>> farm is laid out. There are many valid uses for proxies, apart from
>> caching the Google Doodle of the day to speed up the users' connection
>> and cut down on bandwidth usage.
>
> Isn't that what a firewall does?
I've been to several offices where the IT was configured with a proxy
server as the only access to the outside world. Seems to be quite a
common method in large organisations to control the traffic.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2013-11-14 14:38, Orchid Win7 v1 a écrit :
>> TCP only ensures that data that is split in multpiple packets will be
>> rassembled in the right order at the other end. It does not tell you
>> ahead of time how much data to expect, so you can't know in advance if
>> you should still be waiting for the end of that XML document, or if it
>> was malformed and is missing closing tags, and you should simply
>> reject it.
>
> If the XML is machine-generated, it shouldn't ever be malformed. If it
> is, that's a bug.
A bug that has been exploited by many a malware. ;-) Trust no one!
> (Which I suppose is something real applications have
> to deal with, but it doesn't concern me overly much.)
>
True, but it is a good idea to develop good programming habits and do
some error-checking nonetheless.
To reuse the powertool analogy that you and Warp are discussing, even if
you develop the habit of wearing gloves and protective eyewear everytime
you use your circular saw, even for small jobs, you have a much smaller
risk of injuring yourself, the day you're tearing down the old kitchen
counters and the saw hits a nail and jumps back at you.
>> To prevent unauthorized traffic from leaving or entering your network
>> (or parts of it). To mask the details of how the back-end of your server
>> farm is laid out. There are many valid uses for proxies, apart from
>> caching the Google Doodle of the day to speed up the users' connection
>> and cut down on bandwidth usage.
>
> Isn't that what a firewall does?
>
Firewall only inspect and block unauthorised traffic from leaving or
entering a network, but for them to work, you need an actual route to
the outside world to exist and point to the firewall. With a proxy, you
can actually NOT have any route to the internet on your inside lan.
Your Proxy has two interfaces, one on the inside lan (and everyone uses
that in their broswer config), and another one on an internet-accessible
network. This kills most bots and other malware dead.
In a corporate environment, you'd typically have such a setup to isolate
the developpers (or "guest" wifi access, for example) from the rest of
the production network, so that they can play as much as they want with
their toys while still having access to needed intranet and internet
resources, without impacting the rest of the business.
> The long and short of it is, I managed to configure WCF to *not* use
> HTTP, and it works exactly the same as if it *did* use HTTP. Which, to
> me, rather suggests that using HTTP is a total waste of time.
>
A 30 second google tells me that you can do something called
"NetTcpBinding" instead of "BasicHttpBinding". I have no idea if that
is what you are looking for because I don't know how the framework works
and this was just a blog entry explaining how to tell a server to say
"Hello World!" and it didn't delve into the various intricacies of not
using BasicHttpBinding.
--
/*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
|
|
| |
| |
|
|
|
|
| |
|
|
