Re: Socket write behaviour is inconsistent?

Tech-Archive recommends: Fix windows errors by optimizing your registry

On 2007-11-09 17:07:10 -0800, cjard <mcw8@xxxxxxxxxx> said:

[...]
> 2) Has anyone provided you with a definitive answer based on the
> information you've provided so far?

There are several possible scenarios beyond your answer to your own
rhetoric. In summary, most people reading the question either do not
know the answer, or cannot be bothered to explain it.

Interesting that you don't consider the possibility that the question was simply not presented well enough for a person with the answer to provide that answer.

[...]
I usually demand
a level of precision from others when they ask a question that I know
the answer to, but feel that they have not sifficiently helped
themselves through their own clarity of thought in producing an
understandable description of the problem. If you feel this to be the
case here (to whit; you know the answer but youre taking the same
stance that I take in being bloody minded about the specification of
the question, for my own good), do let me know, wont you? :)

It's not the case at all. Generally, when I feel a person hasn't sufficiently helped themselves, I just ignore them. I would never waste time just trailing them along if I know the answer myself.

And given your elaborations, I am beginning to suspect you will not find the answer here at all, because I suspect the problem has absolutely nothing to do with .NET. The behavior you're describing just isn't the sort of thing that .NET might affect, but it certainly is the kind of thing that mixing and matching different network transports might, or some sort of problem with the client terminal might cause.

Thus, I suspect the latter possibilities over something related to the ..NET implementation of the host.

I definitely do not know the answer to your question as stated, but even as things stand now I have no way to know if that's because the problem has nothing to do with .NET, or because you simply haven't provided enough details.

I do know that there's no way to tell the difference for sure until you do provide more details.

[...]
The terminating 0x03 is mandatory, as far as the spec is concerned.

No doubt that as far as the spec is concerned everything should work
fine as it is now.

I dont really understand this sentence. It apears to be missing some
punctuation.

My point is that given the information you've provided about the spec, everything should work fine.

But that's not really all that relevant, is it?

The spec is relevant; the terminal is asserted to be compliant with
the spec, and I really dont think a couple of people chewing over a
puzzle on Usenet can question every major bank in the UK at this
stage.

Given that everything does not work fine, then obviously some component in your system is not complying with the spec. Thus, the fact the spec suggests everything should work fine is not at all relevant.

The spec itself is relevant, of course. But the fact that the spec says everything should work fine is irrelevant (or rather, it's redundant...by definition, when things comply with a spec, everything works fine so of course a spec would say everything should work fine).

[...]
If you still feel that your question is an appropriate .NET question,
you need to provide more details as I've described.

You touched on the source of my puzzlement in that I have to work
around an issue. Your opinion that the three methods ought be
equivalent was most useful; i concur and I have no explanation for why
I should have to "work round" in this way, or even why sucha "work
round" works at all. If all three methods are functionally equivalent,
why does one fail?

There's no way to answer that question definitively without a concise-but-complete sample of code that reliably demonstrates the problem.

If you cannot create such an example of code using only C#/.NET, then it stands to reason that the problem does not lie within .NET and thus your question cannot be answered here. In that case, it's likely a problem with some other component in your network system. Even if that system works perfectly with some other implementation of the host, all that would mean is that that particular host has worked around the problem (accidently or on purpose, presumably in a manner similar to the method you've already found).

On the other hand, if you _can_ reproduce the problem using only C#/.NET, then if you post the concise-but-complete sample of code that does that, it is _much_ more likely that someone here can answer the question.

But absent that sample, this is the wrong place for you to seek an answer.

Pete

.

Relevant Pages

  • Re: Hand Eye co-ordination
    ... to annoy people is top of the person spec. ... Game show host? ... Presenter of Go For It? ...
    (uk.media.radio.archers)
  • Re: storing temporary variables in dom nodes
    ... On the other hand setting previously undefined properties on host ... Might not be required "by the spec", but de-facto it's a requisite, at ...
    (comp.lang.javascript)
  • Re: DDR MHZ
    ... explains the ratching down of your RAM to PC2700, it keeps the CPU and RAM ... components remain "in spec", i.e., NOT overclocked. ... ANYTHING is suspect at this point. ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: average cost of software projects ?
    ... I guess I find the whole averaging thing very suspect. ... spec one time and I then completed it. ... Constant re-work and discussion with an ever-changing spec would ... people in the stats are doing bug fixes and modifications, feature upgrades, ...
    (borland.public.delphi.non-technical)
  • Re: Java language spec question: statements
    ... Always put around the if then clause. ... So I suspect ... It claims declaration ... and the spec has it right. ...
    (comp.lang.java.programmer)