I've written a window form that send files via a Socket using RSA encryption. I split the file up into peices for sending, I was wondering if there is a generally used buff size for sending over sockets. Right now i split each file up into 100 pieces unless a size is specified by the user. That was mostly for testing, so now I need to set a buffer size to use...any thoughts on the suject ? Whats too big for a socket connection, whats too small ?
Someone please correct me if I'm wrong, but I think it's like this.
Take a look at "MTU". It determines the maximum size of a single packet. In TCP, you don't really have to worry about losing anything, but I think it's more efficient to send it based upon the MTU size. Normal MTU for ethernet is 1500 bytes from what I understand.
I, for one, do not think the problem was that the band was down. I think that the problem may have been that there was a Stonehenge monument on the stage that was in danger of being crushed by a dwarf.
You mean at runtime? .NET framework doesn't provide ability to load types from the embeded assembly at runtime in some way? (I don't mean using Reflection API which requires developer to code, some automatic reference to inside assembly as if it was an external .dll)
This is not practical. The CLR loads Types based on their assembly name (filename, version, culture, and public key token) and loads the Type from the namespace and class name. If you set it as an embedded resource, the CLR can't do its job and JIT'ing your application will fail!
There's nothing wrong with an app that has references to DLLs. Fusion - the part of the Framework that binds assemblies - either pulls DLLs from the application directory or another configured private path (see <probing> in the .NET Framework SDK documentation), or from the global assembly cache (GAC). If the application is deployed from the Internet/intranet using a touchless installation, it will just as easily download the assemblies in the same manner to the temporary assembly cache and load the executable just by clicking a link (or for an embedded user control).
No install is needed (besides the .NET Framework) and you can simply copy files, hence "touchless deployment".
Its quite possible and not too hard, just a bit of work to get it going.
1. Compile dll.
2. Set dll as embedded resource to exe.
3. In main you need to setup an eventhandler to AppDomain assebly resolve event, cant remeber the exact name now.
4. At the event, read the resource stream of the dll (using compression mite be handy), into a byte.
5. Load the assembly via Assembly.Load(byte).
6. Send me a Dell 3Xi for my b-day in a few weeks
Good day to all u programmers out there. Pls could you offer help on the following:
1. I enjoying programming and I also have a great love for database administration...where do I fit in?
2. I seldom use a tool for long before moving around to something new - low persistence...where do I fit in?
I know some of u are professions. Pls help me discover myself (direction and clear advice without any biase)...where do I fit in?
...the mind is not a vessel to be filled but a fire to ignited
When remove a TabPage or Control from a collection like this, make sure you do it in the main UI thread, no another thread. This can lead to problems processing the message loop that internally dispatches messages to the appropriate windows. There are other causes of this behavior and we've discussed it before. You could try searching the comments to find more causes.
Instead of TabPage.Focus, use TabControl.SelectedIndex or TabControl.SelectedTab:
// Initialize the TabPage and its contents
TabPage page = new TabPage("Second");
tabControl1.SelectedTab = page;