I have a C# service application which receives files via UDP and saves them into a local drive. The application runs fine on local OS, but when it's running from a VM I get these exceptions from the Socket lib and the IO lib.
System.Net.Sockets.SocketException (0x80004005): An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full
System.IO.IOException: Insufficient quota to complete the requested service.
I've tested the disk space, but It's 80% free. Also the Ram on the VM is set to 2GB.
I've google but couldn't find much on this topic.
# David Stratton:
Info About the VM system:
Using ESXi 4.1
Host OS windows 2003
# Seth Noble
Your right. The first exception happens when it's sending a packet to the source.
And the Second IO exception when it receives the packets to write to disk.
If this is only happening in thw VM it is most likely a issue with the implementation of some of the features of the actual VM software and it is safe to assume that it is not due to a programming mistake on your part.
Related
The connection with the client was abnormally terminated during the network communication between the server and the client. What should I do in this situation? I do not know which exception to handle.
I would say that the information given is very minimal, but I would suggest you to check the followings to start with
Try pinging the client/server from each other and confirm network connectivity.
Is there a firewall causing network connection to disrupt, you may need to open some ports in that case.
Look into client and server log files - if at all they are there.
Did server process crashed? do ulimit -c unlimited before starting the process.
Did client process crashed? do ulimit -c unlimited before starting the process.
Try doing the connect/send/receive in try-catch blocks, and put proper prints in catch block. There can be a broken pipe exception.
I would say check the buffer size that you are sending or receiving, both client and server should be able to handle the size.
In case you find core files in #2 or #3, load the core and see where it is crashing, it will give you the best hint.
If you are on Linux, try digging out information from system logs - e.g. /var/log/messages etc., if not on Linux find equivalent files.
I can provide more details once the incidence is clear, e.g. what you are trying to send, is it happening every time or some of the times? What is the message printed in catch block?
I have a process, using Selenium Web driver for Firefox, for automatic look up for information on one specific site. Due to the volume of the data being looked up, I am running in parallel several copies of this process. Sometimes they are ok, sometimes I get an exception, which I do not understand the cause for. The Process is written in C#, runs on Windows. Each process creates its own instance of Selenium, FF web driver, I see each process has a separate FireFox process. No multi-treading (inside one process). I do not understand what exactly is the issue. Could not find any documentation that could tell me more.
If anyone has an idea, I'd appreciate any info/suggestions
The exception is:
"OpenQA.Selenium.WebDriverException: Unexpected error. System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: Only one usage of each socket address (protocol/network address/port) is normally permitted 127.0.0.1:7056"
I can not see what can be trying to make more than one "usage" of the socket address in one given process. And from the logs I see that the different processes use different ports ( the "7056" above is a different number in each process).
Thank you in advace
I recently ran into this and found a pretty interesting article about fine tuning your network settings.
https://blogs.msdn.microsoft.com/dgorti/2005/09/18/only-one-usage-of-each-socket-address-protocolnetwork-addressport-is-normally-permitted/
so pretty much if you run a high degree of parallelism in your tests with not enough ports open and a high timeout you will run out of sockets and this will happen. either increase the ports, reduce the wait time and check what can be leaving your instances hanging.
I have an application in C# that is a TCP server listening to a port. GPS devices connect to this port. The application is accepting the TCP client and creating a new thread for each client. The client ID in maintained in a hash table that is updated when a client is connected. this was all working fine until around 400 units. Once the number of units increased, the server was unable to handle all connections. The connections are being continuously dropped and once in awhile leads eating up the server CPU and memory and brings it down. Work around was to open another instance of the TCP server listening to a different port and diverted some units to that port. Currently some 1800 units are somehow running in 8 different ports. The server is extremely unstable and units are still unable to stay connected. Facing too many issues on a daily basis. Also using remoting to send settings via the remoting port - this is working only sometimes.
Please help by giving a solution for TCP socket/threading/thread pooling etc. that is both scalable and robust and can in a single port.
This TCP server is running in Windows server 2008 R2 Enterprise with IIS7 and SQL server 2008.
Processor: Intel Xenon CPU E3-1270 V2 #3.50GHz
RAM: 32GB
System: 64-bit operating system
Thanks
Jonathan
Basically, don't use a thread per socket; use one of the async APIs (BeginReceive / ReceiveAsync), or some kind of socket polling (Socket.Select for example, although note that this is implemented in a very awkward way; when I use this, I actually use P/Invoke to get to the raw underlying API). Right at this moment, I have > 30k sockets per process talking to our web-sockets server (which is implemented via via Socket). Note that for OS reasons we do split that over a few different ports - mainly due to limitations of our load-balancer:
One thread per connection is not a really good idea specially when you have to handle 100s of client concurrently.Asynchronous is the way to go with some buffer pooling/managing. If you are looking for something to start with asynchronous sockets have a look at this basic implementation if you are looking for something complete Take a look at this(explanation: Here)
If you are willing check this out too.
In C# you can go with classical BeginXXX/EndXXX methods. Microsoft also have a High Performance Socket API which can be leveraged using XXXAsync methods. A few articles which explain the High Performance Socket API Here and Here
I am looking for a way to transfer a lot of files over a long period of time from a client to a server.
The connection between the client and the server is not reliable and slow.
I thought about using the FTP protocol. I saw the netftp client.
I now need a ftp server in .net also.
The most important feature that I need is reliable connection resuming. Something that I can rely on to just start and end over a period of time reliably.
I didn't find many ftp servers that were written in c#.
Thank you.
you can use Background Intelligent Transfer Service in windows.
http://msdn.microsoft.com/en-us/library/bb968799(v=vs.85).aspx
Use BITS for applications that need to:
Asynchronously transfer files in the foreground or background.
Preserve the responsiveness of other network applications.
Automatically resume file transfers after network disconnects and computer restarts.
a .net wrapper is available for BITS - http://sharpbits.codeplex.com/
We have a WCF Service Application consuming a large amount of memory (see my other ticket today at: Server is leaking memory; but process looks fine).
After extensive use of the Windows Service Application at a sudden moment the whole service crashes. During this moment:
The log (WCF-Trace/Server DB Log) does display activity, but no leads.
The memory is high, but no out of memory exception Server is leaking memory; but process looks fine
Number of open connections; just before 'the crash': 10 - 20
The memory dump shows 8 threads, without an interesting stack trace. These are only small stacks, without any user code (only calls in Microsoft-symbols)
Can do:
Attach the Remote Debugger;
Connect to the port WCF is listing to;
Can't do:
Remote Debugger; Break all does not respond
Attach SciTechMemoryProfiler (exception: 0x80007002)
Response to any call of WCF;
The memory is still completely in use, but the server is completely unresponsive.
thanks for reading this ticket.
We found the solution. We analyzed the dump file with WinDebug, and found a single function in the dump. We don't know if it was luck or expected behaviour for a Windows Service in .Net , but from there we were able to replicate the issue.
Thanks all for reading, and hopefully you can make progress with this 'solution'.