thank you for your response. I will try to research abit and see what i can
learn from this. I am not sure if you all have seen my first post regarding
this. I always get an exception when the java webservice returns a soap fault.
the stack trace of the exception is below. is this a common or r
.NET treats soap faults as a SoapException. From the SoapException is an
optional Detail element that you can use to parse the actual fault returned
by the server. Even if the WSDL for the java webservice indicated the faults
involved in their operation, .NET generators (WSDL.exe/VS.NET add web
ref
It raises a SoapException ...
You can workout the original exception on the server via the message but
the inner exception is null.
Also note you can get other exceptions such as NetException for the
transport layers
Regards ,
Ben
> -Original Message-
> From: Unmoderated d
could anybody find a solution to my problem. Where do i get information on
how .net framework would treat soap faults. i read some where that .net
framework would raise an exception when it gets a soap fault as a response.
is it necessary that the exception class(that is in java) be on the client
s
Yeah this should be fine. Basically you are opening a HttpWebRequest
and keeping it alive so that you can have a connection between IIS and
Client B.
The only issue I can see with this is does it support two-way
communication? If it does than everything is sweet, otherwise it may
prove expensi
I would do item [1] below and run the worker process under a domain
account. From your note you did not indicate your OS.
If you are Win2K modify the processModel tag under the web.config section
in your machine.config file. Change the settings userName="machine"
password="AutoGenerate" to userN
I haven't done this sort of thing for a while, since ASP in fact. But by the
looks of it, its impersonation that you want to do. This can apparently be
done without changing code, by putting a username/password into the
web.config file.
These might help:
http://aspalliance.com/336
http://idunno.o
I'm no expert in that area, but I believe in Win2K ALL ASP.NET
applications run under the same context (Win2003 uses pools to separate
apps), so it will affect any other ASP.Net apps on that server. I think
you can set this in machine.config on the server. Search MSDN for
"ASP.NET Process Identit
Well, things are a little bit more complicated. The Web Service receives the
full path of a process' config file (MyApp.exe.config). It opens the config
file (which is an XML file) and in the Application Settings section finds
where the activity and error logs for that process are located. It then
If the software that's calling the Web Service delivered the contents of the
XML files, rather than their names, that would make the security much easier
from the WS side -- it would have the XML to process "in hand" rather than
having the file names. In some sense, that's "cleaner" as the XML
Hi Don,
I would incline to use 1) as it would require 0 code to write. This WS is
for a system that's already in production and it was meant to create reports
from the activity and error log files for every process in the system. It's
the last piece that we need to deploy and I don't want to go th
Funny, I've been working on the exact same issue the last few days.
Here are some options (probably not an exhaustive list) in no particular
order:
1) Run the web service under the context of a network-aware user
2) Use delegation in the Web Service to impersonate a network-aware user
3) Use a COM
Hello experts,
I have this small problem with a Web Service that's suppose to open a bunch
of XML files and create a report (in the form of another XML file). If the
XML files reside locally, on the same machine as the Web Service, everything
is fine. The Web Service is able to open them and creat
Chris,
Thanks for the reply and time on this theory.
Basically what you discribed is kinda what im doing
now, except for
holding an active connection.
What I propose is instead of clientB asking if there
is data, IIS uses
that active Connection that it is holding and sends
the data to Clien
Thanks a lot to all of you! Ill go for a message header then... 4 byte
header containing just the length, or perhaps some additional information
like message type and version too.
===
This list is hosted by DevelopMentor® http://www.develop.com
View archives and m
There are really just two solutions to your problem:
1. Always use messages of a fixed size. If the encoding of you message is
smaller, you need to pad it with 0s at the end.
Advantages:
- you don't need to care about the size of the packet to be sent;
Disadvantages:
- you send useles
That's correct - I believe it's known as a TCP slow start
If performance is critical then *do not* tear down the connections each
time. Modern TCP protocol stacks are full-duplex - meaning that both client
and server can send/receive at the same time. Knowing this you can
'pipeline/multiplex' send
Użytkownik Ragnvald Barth <[EMAIL PROTECTED]> napisał:
>Thanks a lot Andrew Gayter, for helping me understand...
>Could I solve the problem by disconnecting the socket, and reconnect for
>each new message?
This is possible but of course a worse approach, as connection establishment
takes some tim
Użytkownik Ryan Heath <[EMAIL PROTECTED]> napisał:
>Hi Ragnvald Barth,
>
>I think you should incorporate the message length/type within the message.
>
>Specific message have certain lengths or bake in a length specifier in
>the message.
That's right, TCP data are treated as a "stream" of bytes. If
Thanks a lot Andrew Gayter, for helping me understand...
Could I solve the problem by disconnecting the socket, and reconnect for
each new message? I have to get the details right here, because both
performance and stability will be critical in the end...
===
This l
Hi Ragnvald Barth,
I think you should incorporate the message length/type within the message.
Specific message have certain lengths or bake in a length specifier in
the message.
Message
{
byte type;
object data;
}
or
Message
{
int length;
object data;
}
or do both
Message
{
byte type;
int le
When you use connection oriented communication i.e. connected sockets you
affectively have a stream between client/server. Think of this stream as
being a file - the client writes to the file and the server reads from the
file.
If you were actually using a file, how would you distinguish between
me
Can I send multiple messages using the same socket, and still distinguish
where one message stops and the next one begins?
I send messages between server and client using sockets:
The client side code is like this:
IPEndPoint ipe = new IPEndPoint(address, port);
Socket socket = new Socket(ipe.Add
23 matches
Mail list logo
